To the Clearwater community, We're planning on adding support for TEL URIs (RFC 2806 and RFC 3966) in a future release. The main areas of change to Clearwater will be to accept TEL URIs in requests, and to perform ENUM lookups in a spec compliant fashion.
I've put a description of the changes we're intending to make below - please do let us know if you have any feedback on them! Thanks, Ellie Accepting TEL URIs in request URIs, REGISTERs and SUBSCRIBEs: The current Clearwater behaviour is to check the URI scheme of a request as part of verifying its validity, and reject any requests that aren't SIP URIs. REGISTERs and SUBSCRIBEs also only accept SIP URIs. The S-CSCF is changed to accept TEL URIs as well as SIP URIs; TEL URIS can be accepted anywhere in a SIP message that a SIP URI is valid. If a TEL URI is invalid, then the processing and result is the same as when a SIP URI is invalid in the same location (i.e. the request is rejected). Clearwater will also accept TEL URIs in REGISTERs and SUBSCRIBEs, and use the TEL URI as the public user identity. Every implicit registration set must include at least one SIP URI (TS 23.228, 4.3.3.2 - policing this will be added in a later release). Performing ENUM lookups (TS 24.229, 5.4.3.2): The current Clearwater behaviour is to always perform ENUM lookups on a request directed at the home domain, independent of whether it's a local/global number, or whether (if it's a SIP URI) it contains the URI parameter 'user=phone'. If the ENUM lookup succeeds, the request URI is rewritten. If the ENUM lookup returns no matches, the request processing continues with the existing request URI. This isn't spec compliant; two of the main differences are that we don't treat local and global numbers differently (as defined in RFC 3966), and we don't check whether the user=phone parameter is present on SIP URIs (we don't do the check as we've found that few SIP phone actually add this parameter). To allow configuration and backward compatibility, two new configuration options are added: - --enforce-user-phone - This controls whether ENUM lookups are only done on SIP URIs if they contain the SIP URI parameter user=phone (defaults to false). - --enforce-global-only-lookups - This controls whether ENUM lookups are only done when the URI contains a global number (defaults to false). The logic for handling (valid) TEL/SIP URIs is as follows, depending on whether it represents a phone number, and whether it's ENUM routable. Does the URI represent a phone number? - YES: if it's a TEL URI, or a SIP URI for the home domain with user=phone, - POTENTIAL: if it's a SIP URI for the home domain with a numeric user part and enforce-user-phone is false. - NO: All other cases. Is the number ENUM resolvable? - YES: If the number in the URI is a global number (as defined in RFC 3966), or enforce-global-only-lookups is false. - NO: All other cases. The URI represents a phone number (YES or POTENTIAL) and the number is ENUM resolvable: The S-CSCF attempts to translate the address to a routeable SIP URI using an ENUM/DNS translation. - If the lookup succeeds, update the request URI and continue processing - If the lookup fails, then: o If the URI definitely represents a phone number (YES) then forward the request to the BGCF unchanged (note that if a TEL URI is forwarded to the BGCF, the BGCF will only be able to forward it on to the default domain) o Otherwise (POTENTIAL), continue processing as normal with URI unchanged Examples: - A SIP URI where the user part starts with +, the 'user' SIP URI parameter equals 'phone' and the domain name of the SIP URI belongs to the home network - A SIP URI where the user part starts with + and the domain name of the SIP URI belongs to the home network, and enforce-user-phone is false - A SIP URI with a local number in the user part and the 'user' SIP URI parameter equals 'phone' and the domain name of the SIP URI belongs to the home network if enforce-global-only lookups is false - A SIP URI with a local number in the user part and the domain name of the SIP URI belongs to the home network and enforce-user-phone and enforce-global-only-lookups is false - A TEL URI containing a global number - A TEL URI containing a local number and enforce-local-numbers is false The URI represents a phone number and the number is NOT ENUM resolvable: If the URI definitely represents a phone number (YES) then reject with a 484 Otherwise (POTENTIAL) then continue processing the request as normal Examples: - A SIP URI with a local number in the user part and the 'user' SIP URI parameter equals 'phone' and the domain name of the SIP URI belongs to the home network if enforce-global-only lookups is true - A SIP URI with a local number in the user part and the domain name of the SIP URI belongs to the home network and enforce-user-phone is false and enforce-global-only-lookups is true - A TEL URI containing a local number and enforce-local-numbers is true The URI does NOT represent a phone number and the number is ENUM resolvable: Continue processing the request as normal and don't do an ENUM lookup Examples: - A SIP URI where the user part starts with + and the domain name of the SIP URI belongs to the home network, and enforce-user-phone is true - A SIP URI with a local number in the user part and the domain name of the SIP URI belongs to the home network and enforce-user-phone is true and enforce-global-only-lookups is false The URI does NOT represent a phone number and the number is NOT ENUM resolvable: Continue processing the request as normal and don't do an ENUM lookup Examples: - A SIP URI with a domain name that doesn't belong to the home network The BGCF is enhanced to accept TEL URIs: note that these will always be routed to the default domain (if it exists in the BGCF configuration). There are also a number of smaller changes required to support TEL URIs in order to be fully spec compliant - these are described below and will be added in a later release. I-CSCF - Initial requests (TS 24.229, 5.3.2.1): When the I-CSCF receives an initial request where: - The Request-URI includes a (non GRUU) SIP-URI - Its user part starts with a + - Its "user" SIP URI parameter is "phone" The I-CSCF replaces the Request-URI with a TEL-URI with the user part of the SIP-URI in the telephone-subscriber element in the TEL-URI, and carries forward any TEL-URI parameters that may be present in the Request-URI. I-CSCF - Unsuccessful user location query (TS 24.229, 5.3.2.1): If the I-CSCF does an unsuccessful user location query where: - The response from the HSS indicates that the user does not exist - The Request-URI is a valid TEL URI The I-CSCF attempts to translate the number in the TEL URI to a routeable SIP URI. If the translation fails, then the I-CSCF returns a 404/604. If the translation succeeds, then the TEL URI in the request URI is replaced with the SIP URI. S-CSCF - P-Asserted-Identity (TS 24.229, 5.4.3.2/3) When the S-CSCF receives an initial request, or a 1xx/2xx response to a an initial request, and the request doesn't have an ODI, then: - If the P-Asserted-Identity header contains only a SIP URI, and the S-CSCF knows that the SIP URI is an alias for a TEL URI, then the S-CSCF adds a second P-Asserted-Identity header containing this TEL URI. - If the P-Asserted-Identity header contains only a TEL URI, the S-CSCF adds a second P-Asserted-Identity header containing a SIP URI of the form <sip:+(number from TEL URI)@(user's home domain)>;user=phone;(TEL URIs display name) _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
