Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
UAC Behavior
A UAC that is about to send an INVITE message to an address of a dial string MUST use the following logic. If a UAC cannot resolve the dial string to a SIP URI with an E.164 number of a remote party, based on local provisioning, it MUST set the SIP URI of the Request URI header with a phone number and a phone-context of the phone number in the user part of the SIP URI, as specified in [RFC3966] section 5.1.5. The value of the phone-context SIP URI parameter holds the location profile name of the user if the dial string could not be resolved or the resolution of the dial string is to a non-E.164 number. If a user profile name is not provisioned and the dial string is not an E.164 number, the user agent MUST set phone-context to the default predefined dialstring name.
Callback presents another case where an outgoing call can have a Request URI and To URI containing a phone-context parameter. An incoming call to a UA can have a P-Asserted-Identity (PAI) header containing a non-E.164 number with a phone-context of "dialstring". Alternatively an incoming call to a UA can have a P-Asserted-Identity header containing a non-E.164 number with a phone-context of "enterprise". If the callback feature is implemented in the UA, the value of the P-Asserted-Identity header SHOULD be used to populate the Request URI and To URI fields in the INVITE triggered by the callback.
A UAC SHOULD<2> set a valid
SIP URI in the From header. If the SIP URI is in a phone number format, user=phone, the phone number SHOULD<3> be in either E.164 format or a
private number with a phone-context that is set with the location
profile of the UAC.
UAS Behavior
If a UAS has a gateway role, it SHOULD include a P-Asserted-Identity in the 200 OK that it sends in response to an initial INVITE used to establish a dialog. This 200 OK is derived by using the Request URI from the initial INVITE used to establish the dialog. If this Request URI is used, and it contains an E.164 number in the user part, the UAS SHOULD copy it to the PAI. If this Request URI is used, and it contains a non-E.164 number in the user part, the UAS SHOULD copy it to the P-Asserted-Identity (PAI) and the phone-context SHOULD be set to the location profile of the UAS.
Proxy Behavior
A SIP proxy that receives a SIP URI with a phone-context in the Request URI MUST try to match the phone-context name with a list of provisioned dial plan names. If there is a match, it MUST convert the SIP URI based on the rules that are defined in the matched dial plan. Otherwise if there is no match, it SHOULD use other proxy logic to route this URI.
A P-Preferred-Identity header is a SIP header field, as described in section 9.2 of [RFC3325], which carries the preferred identity for the user sending the SIP message. This header field is sent by a UA to a trusted proxy to be inserted as the value in the P-Asserted-Identity (PAI) header field.
A SIP proxy that receives an INVITE that contains a phone-context in the From URI SHOULD<4> try to match the phone-context name with a list of provisioned dial plan names. If there is a match, and the INVITE does not contain a P-Asserted-Identity (PAI) or P-Preferred-Identity header, the proxy SHOULD<5> apply the rules defined in the matched dial plan and add a P-Asserted-Identity (PAI) with the result of the translation. If the result of the translation is not an E.164 number, the proxy SHOULD<6> insert a phone-context with the value "enterprise".