Multi-Identity Scenarios (Shared Numbers and Multi-MSISDN)

This guide explains how OmniCSCF handles the two "one subscriber, many identities" models that IMS supports. It covers registration, terminating-call forking, the fork reject behaviour, and originating-call identity selection. It documents what each network element sees.

The two models are independent. A subscriber can use either, both, or neither.

• Shared Public User Identity (one number, several devices). One number is served by several devices on separate SIMs. A phone and a smartwatch are the common example. Each device has its own IMSI (private identity, IMPI). The devices share one public identity (IMPU, the number).
• Multi-MSISDN (one device, several numbers). One subscriber (one IMSI) has several numbers. A personal number and a business number on the same device are the common example. The device registers all of its numbers as public identities.

Table of Contents

1. Identity Model
2. Registration
3. Terminating Calls to a Shared Number
4. Fork Reject Behaviour
5. What the Application Server Sees
6. Terminating Calls to a Multi-MSISDN Subscriber
7. Originating Calls and Calling-Line Identity
8. Reference

Identity Model

3GPP TS 23.228 defines the IMS identity model. A private identity (IMPI) identifies a subscription for authentication. A public identity (IMPU) is a number or a SIP URI that other users call. One subscription can hold several public identities. Several private identities can share one public identity.

The HSS holds the model. The S-CSCF downloads it in the User-Data at registration (Cx Server-Assignment, TS 29.228). The set of public identities that register together is the implicit registration set (TS 23.228).

Registration

Each device authenticates with its own private identity. The S-CSCF challenges every REGISTER and validates the response against a Cx authentication vector (see the S-CSCF guide). On success the S-CSCF stores one contact binding per device.

The 200 OK to the REGISTER carries a P-Associated-URI header. This header lists every public identity in the subscriber's implicit registration set. The device learns its numbers from this header.

• Shared number. Each device registers with its own private identity under the same public identity. The S-CSCF keeps one contact per device. The S-CSCF matches contacts by contact URI, so the devices do not overwrite each other. The S-CSCF keeps up to maxcontact contacts per public identity. Set maxcontact to the maximum number of devices that share a number.
• Multi-MSISDN. The device registers with its one private identity. The 200 OK P-Associated-URI lists all of the subscriber's numbers. A terminating call to any of the numbers reaches the device.

Terminating Calls to a Shared Number

A call to a shared number must ring every device. The S-CSCF does the forking. When the S-CSCF resolves the terminating location with lookup("location"), the append_branches parameter appends every registered contact as a parallel branch. The S-CSCF sends the INVITE to all devices at the same time (a parallel fork, TS 24.229 and RFC 3261 section 16).

The first device to answer wins. The S-CSCF forwards that device's 200 OK to the caller. The S-CSCF sends a CANCEL to every other branch. The other devices stop ringing.

The S-CSCF guide documents the append_branches and maxcontact parameters.

Fork Reject Behaviour

A device can reject a forked call instead of answering it. The response code decides whether the other devices keep ringing. This follows the parallel-fork response rules in RFC 3261 section 16.7. The S-CSCF transaction layer applies these rules.

A device responds with	Meaning	Effect on the other devices	Caller result
200 OK	The device answered	The S-CSCF sends CANCEL to the others. They stop ringing.	Call connects to the first device that answered.
4xx (for example 486 Busy Here, 480 Temporarily Unavailable)	This one device cannot take the call	The others keep ringing. That branch drops out.	The caller sees a failure only after every device fails. The S-CSCF then forwards the most preferred final response.
5xx (for example 500 Server Internal Error)	A server error on that branch	The others keep ringing. That branch drops out.	Same as 4xx: a failure reaches the caller only after every branch fails.
6xx (for example 603 Decline, 600 Busy Everywhere)	A refusal for the whole identity, not just one device	The S-CSCF sends CANCEL to the others. They stop ringing.	The caller receives the 6xx.
No response (timeout)	The device is unreachable	The others keep ringing. The branch times out (fr_inv_timer).	Same as 4xx: a failure reaches the caller only after every branch fails.

The key distinction is 6xx against 4xx/5xx. A 4xx or 5xx is a failure of one branch only, so the fork continues. A 6xx is a global refusal for the identity, so the S-CSCF cancels the whole fork. To decline a call on all of a subscriber's devices at once, a device must send a 6xx. To reject on one device while the others keep ringing, a device must send a 4xx.

What the Application Server Sees

The MMTel Application Server (the TAS) sits in the terminating path before the fork. The S-CSCF triggers the TAS with the terminating Initial Filter Criteria. The TAS applies its services. The TAS then returns the session to the S-CSCF. The S-CSCF resolves the contacts and forks.

Therefore the TAS handles one terminating session toward the shared identity. The TAS does not see the individual device branches. The fork is transparent to it. The TAS sees the consolidated result:

• one ringing indication,
• then the single winning 200 OK, or
• the aggregated final failure, or
• the 6xx decline.

The TAS controls whether the S-CSCF forks. For a shared identity the TAS allows forking, so the S-CSCF rings every device. For a single-device identity the TAS sets Request-Disposition: no-fork, so the S-CSCF sends the call to one contact. The TAS makes this decision from the number of members in the shared identity, which it reads from the HSS over Sh. The per-device response handling stays inside the S-CSCF.

Reject, and the voicemail decision

A common question is whether the TAS sees one device reject the call, while the other devices still ring, so that the TAS can forward the caller to voicemail. It does not. The TAS sees only the final result of the whole fork. The fork is inside the S-CSCF, downstream of the TAS.

• One device that sends 486 Busy Here does not, on its own, reach the TAS. The other devices keep ringing. The S-CSCF holds the transaction open. The TAS is not notified.
• The TAS receives a final response only when the fork resolves. The fork resolves when a device answers (200), when every device has failed, or when a device sends a 6xx.
• When every device fails, the S-CSCF selects one final response for the whole fork. It selects the most preferred response among the branches (RFC 3261 section 16.7). The S-CSCF returns that one code to the TAS. The TAS does not see the separate per-device codes.
• The TAS then applies its Communication Forwarding logic to that one final code. The TAS forwards the caller to voicemail on the conditions it is configured for (for example Communication Forwarding on Busy for 486, or on No Reply for a timeout). Voicemail is therefore reached when the whole fork fails, not when one device rejects.

A 6xx (for example 603 Decline) is different. A device that sends a 6xx cancels the whole fork. The S-CSCF returns the 6xx to the TAS. The TAS treats this as an explicit refusal for the identity. Whether the TAS then forwards to voicemail depends on the Communication Forwarding rules configured for a declined call.

In short: a per-device "this device declined, so send that caller to voicemail while the other devices keep ringing" behaviour is not possible with a network fork. Voicemail is a property of the whole shared identity. The caller reaches it only when the whole fork fails.

Worked example: every device returns 480

Two devices share a number. A call forks to both. Both reject with 480 Temporarily Unavailable a few milliseconds apart. This is what happens on the wire:

1. The S-CSCF receives both 480 responses. Each response carries its own device's headers (its own User-Agent, its own To tag, and any extra headers the device added). Both share the forked Call-ID and CSeq.
2. The S-CSCF selects one of the two 480 responses and forwards it upstream. It forwards that branch's actual response (standard proxy processing: it removes its own Via and leaves the rest). The forwarded 480 keeps the selected device's User-Agent, its Reason header (for example Reason: Q.850;cause=18), and any extra headers that device set. It is a real single-device response, not a merged one.
3. The selected response is not "the last device to reject". The S-CSCF selects the branch by its own transaction rules. When every branch returns the same code, the selection follows branch order, not reply order. Do not depend on which device the forwarded 480 (and its User-Agent) came from. Only the response code is reliable.
4. The Application Server sees that one 480, applies Communication Diversion for a not-reachable subscriber (480 maps to CFNRc), and forwards the caller to voicemail. The caller connects to voicemail with a 200 OK.

If the devices return different reject codes, the S-CSCF selects the most preferred one per RFC 3261 section 16.7, and the Application Server acts on that single code.

Worked example: one device rejects, another answers

Two devices share a number. A call forks to both. One device rejects with 480. The other device rings and then answers. This is what happens on the wire:

1. The 480 from the first device arrives, even before the second device rings. The S-CSCF does not end the fork on this 480. A 4xx ends only that one branch. The S-CSCF keeps waiting for the second device.
2. The second device sends 180 Ringing, then 200 OK.
3. The 200 OK wins. The S-CSCF forwards the 200 to the caller. The caller connects to the device that answered.
4. The earlier 480 is discarded. It is a losing branch. The caller never sees it, and the call does not go to voicemail.

This confirms the core rule: a device that rejects with a 4xx cannot block a different device from answering. Only a 6xx (or every branch failing) prevents the call from connecting.

Terminating Calls to a Multi-MSISDN Subscriber

A multi-MSISDN subscriber has one device and several numbers. A call to any of the numbers reaches the one device. The number that the caller dialled stays in the Request-URI, so the device can show the dialled number to the user (for example to separate a business call from a personal call).

All of the numbers belong to one implicit registration set. Therefore each number resolves to the same device contact. The S-CSCF resolves the terminating location the same way as any other call. There is no fork, because there is one device.

To provision a multi-MSISDN subscriber, add every number as a public identity to the one IMS subscription in the HSS. The 200 OK to the REGISTER then lists every number in the P-Associated-URI. See the HSS multi-MSISDN documentation.

Messaging to a Shared Number

SMS over IMS uses a SIP MESSAGE request (TS 24.341). A message to a shared number reaches every device, the same way a call forks to every device. The S-CSCF resolves the registered contacts and delivers the message to each one. Every device on the shared number receives the message.

A message to a multi-MSISDN number reaches the one device, the same way a call to any of its numbers reaches the one device.

Originating Calls and Calling-Line Identity

A subscriber presents a calling-line identity (CLI) on an originating call. A multi-MSISDN subscriber can present any of its own numbers. For example the subscriber presents the business number for a business call and the personal number for a personal call. The device chooses the number in the P-Preferred-Identity header (TS 24.229).

The P-CSCF asserts the identity. The device does not. The P-CSCF applies these rules on every originating request:

1. The P-CSCF removes any P-Asserted-Identity that the device sends. The device is not trusted to assert its own identity.
2. If the device sends a P-Preferred-Identity, the P-CSCF checks it against the subscriber's registered identities. If it is one of them, the P-CSCF asserts it in a P-Asserted-Identity header.
3. If the device sends no P-Preferred-Identity, or an identity that is not registered to the subscriber, the P-CSCF asserts the subscriber's default (primary) public identity.

The identity the far-end user finally sees also depends on Application Server policy. The MMTel Application Server can override the asserted identity (for example a network can normalise every call to the subscriber's primary number, or apply a Calling Line Identification Restriction). To present a non-primary number to the far end, the Application Server must keep the P-CSCF-asserted identity. See the Application Server documentation for the CLI policy.

See the P-CSCF guide for the identity-assertion configuration.

Reference

Response Codes in a Fork

Code	Name	Class	Fork effect
180	Ringing	1xx	Progress. The branch is still active.
200	OK	2xx	Answer. Wins the fork. Cancels the others.
486	Busy Here	4xx	This branch fails. The others keep ringing.
480	Temporarily Unavailable	4xx	This branch fails. The others keep ringing.
408	Request Timeout	4xx	This branch fails. The others keep ringing.
600	Busy Everywhere	6xx	Global refusal. Cancels the whole fork.
603	Decline	6xx	Global refusal. Cancels the whole fork.

Related S-CSCF Parameters

Parameter	Purpose
ims_usrloc_scscf maxcontact	Maximum contacts kept per public identity. Set it to the maximum number of devices that share a number.
ims_registrar_scscf append_branches	When set to 1, a terminating lookup("location") forks to every registered contact in parallel.
tm fr_inv_timer	The INVITE branch timeout. A device that never responds fails when this timer expires.

See the S-CSCF guide for the full parameter reference.

3GPP and IETF References

Specification	Relevance
3GPP TS 23.228	IMS architecture, public and private identities, implicit registration set
3GPP TS 24.229	IMS SIP profile, originating and terminating identity handling
3GPP TS 29.228	Cx interface, User-Data, shared public identities
RFC 3261 section 16.7	Proxy response processing and parallel-fork reject handling