A typical proxy server inserts a P-called-party-id header domain when routing INVITE requests to a destination. The header field is filled in with the request-uri of the PORXY received request. UAS identifies from several registered aors which AOR the session invitation is sent to.
Users of the 3GPP IMS can obtain one or more SIP URIs (AOR) that identify the user. For example: A user can obtain a business SIP URI and a personal SIP URI. One application case is that the user can make the business SIP URI valid only for the work partner and the personal SIP URI is valid only for family members. At a specific point in time, both the business SIP URI and the personal SIP URI are registered to sip registrar, so that two URIs can accept new session invitations. When the user receives an invitation to join the session, he/she should know which of the several SIP URIs the session was sent to. This requirement is mentioned in the 3GPP R5 in the demand for sip[4].
This problem occurs when the SIP proxy for the UA service obtains INVITE, and then the Request Request-uri field is relocated and replaced with the advertised SIP URI of the Contact header field in the register request at the time the user registers. End of the session.
When UAS receives SIP INVITE, it cannot determine which AOR the request is sent to. Some people may feel that the To header field indicates a semantically called user, so there is no need to extend the SIP. Although the To header domain field of the SIP means the called party ID in most cases, it is not correct in the following two special cases:
1. The session is preceded by a SIP proxy forward (forwarded), redirect (redirected), and so on before reaching the proxy server for the user Service.
2. UAC constructs a To header field that is not the same as the Request-uri INVITE request.
The problem with the use of the To Header field is that it can only be completed by UAC and cannot be modified by the agent on the path.
If for some reason UAC does not fill in the To Header field with the target user's AOR, the target user will not be able to distinguish between
The AOR the session expects.
Another possible solution to this problem is that when registering, different AOR use the Contact header field values that are not used.
The UA is able to assign different contact header field values to differentiate between different AOR. For example, when the UA registration Aor,sip:id1,contact header field can be sip:[email protected]; The registration of SIP:ID2 can be bound to the Contact field Sip:[email protected]
The scenario described above assumes that the UA explicitly registers each of its AOR, and therefore must have full control over the allocation to each registration
's contact address.
However, if the UA does not fully control its registered AOR, such as a third-party registration, this scheme will not work. 3GPP may be such a registration scenario: UA can pre-instruct the network outside of SIP when UA registers a specific AOR,
Some other AOR URIs can be automatically registered. This requirement is covered by the 3GPP R5 demand SIP [4].
In the next paragraph we give an example of this problem, it is the case that there is already an orderly call forward in the conversation, so UAC does not know the actual target URI of the current INVITE.
We assume that the user agent (UA) is registered to the proxy server (P1).
Scene UA---P1
F1 Register UA-P1
REGISTER sip:example.com sip/2.0
VIA:SIP/2.0/UDP 192.0.2.4:5060;BRANCH=Z9HG4BKNASHDS7
To:sip:[email protected]
From:sip:[email protected];tag=456248
call-id:843817637684230998sdasdh09
cseq:1826 REGISTER
Contact:sip:[email protected]
The user registers its personal URI also to the proxy server (P1).
F2 Register UA-P1
REGISTER sip:example.com sip/2.0
VIA:SIP/2.0/UDP 192.0.2.4:5060;branch=z9hg4bknashdt8
To:sip:[email protected]
From:sip:[email protected];tag=346249
Call-id:2q3817637684230998sdasdh10
cseq:1827 REGISTER
Contact:sip:[email protected]
Then, Agent Registrar (P1) receives a INVITE request from another proxy server (P2) that targets the SIP AOR for that user's business. We assume that the SIP INVITE has undergone a series of forward turns before, so it is not the user's AOR to fill in the To Header field values. In this case we assume that the session was originally sent to sip:[email protected]. SIP Server othernetwork.com forward the session to sip:user1-business @example. com.
Scene UA---P1---P2
F3 Invite P2, P1
INVITE Sip:[email protected] sip/2.0
VIA:SIP/2.0/UDP 192.0.2.20:5060;branch=z9hg4bk03djaoe1
To:sip:[email protected]
From:sip:[email Protected];tag=938s0
call-id:843817637684230998sdasdh09
Cseq:101 INVITE
The proxy server P1 locates the target user and replaces Request-uri with the Contact field value when it is registered.
F4 Invite P1-UA
INVITE Sip:[email protected] sip/2.0
VIA:SIP/2.0/UDP 192.0.2.10:5060;branch=z9hg4bkg48sh128
VIA:SIP/2.0/UDP 192.0.2.20:5060;branch=z9hg4bk03djaoe1
To:sip:[email protected]
From:sip:[email Protected];tag=938s0
call-id:843817637684230998sdasdh09
Cseq:101 INVITE
When UAS receives INVITE, it does not determine whether the business URI or the personal URI received the session invitation. Neither UAS nor the proxy server nor the application server can make a judgment on the provision of session target AOR. Our solution to this problem is to allow the user's attribution domain Proxy server (defined in SIP) to insert a P-called-party-id header domain that identifies the AOR of the session target.
If this SIP extension is used, the called user Proxy will be filled in F6 P-called-party-id with Request-uri in F5 after obtaining the message F5.
Message flow F5 and F6 content are as follows:
F5 Invite P2, P1
INVITE Sip:[email protected] sip/2.0
VIA:SIP/2.0/UDP 192.0.2.20:5060;branch=z9hg4bk03djaoe1
To:sip:[email protected]
From:sip:[email Protected];tag=938s0
call-id:843817637684230998sdasdh09
Cseq:101 INVITE
F6 Invite P1-UA
INVITE Sip:[email protected] sip/2.0
VIA:SIP/2.0/UDP 192.0.2.10:5060;branch=z9hg4bkg48sh128
VIA:SIP/2.0/UDP 192.0.2.20:5060;branch=z9hg4bk03djaoe1
To:sip:[email protected]
From:sip:[email Protected];tag=938s0
call-id:843817637684230998sdasdh09
P-called-party-id:sip:[email protected]
Cseq:101 INVITE
When UA receives INVITE request F6, it can determine the purpose of the session AOR, and can provide the corresponding service according to this AOR.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
P-called-party-id header Field
