Patent Application
20070266085
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention that together with the description serve to explain the principles of the invention, wherein:
Reference will now be made to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings.
According to a first embodiment of the present invention, when the application server originates a request on behalf of an unregistered IMS subscriber, the application server sends a location information request message to the home subscriber server, through an existing Sh interface, for querying a default server name and the capabilities of the subscriber. It should be noted that the capabilities may be mandatory or optional. If the default server name is provided in a location information answer/response, then the request is routed to the default server name, otherwise, the application server selects, based on the received capabilities in the location information answer, a suitable Serving Call Session Control Function (S-CSCF) in the network and their supported capabilities. This information is configured to the application server. The application server indicates in the SIP message that the S-CSCF should serve the request as an “originating” request by putting an ORIG parameter to URI of the S-CSCF.
The 3GPP 29.228 (version 7.0.0) specification discloses procedures in the home subscriber server for responding to the location information request. According to current procedures, if the subscriber is not registered in the IMS, then the home subscriber server sends a Server-Capablities Attribute Value Pair (AVP), as required for S-CSCF selection, in the location information answer message only if unregistered services are provisioned for the user. This causes the application server's originating request to fail for such users who do not any services that should run in an unregistered state. As such, in a first solution implemented in the first embodiment of the present invention, the I-CSCF indicates to the home subscriber server, in a location information request message, that a location information query is being made for the originating request. If the subscriber, in this embodiment, is not registered to the IMS, then the home subscriber server provides the Server-Capabilities AVP in the location information response message, for such location information request message that includes an indication of the originating scenario, even if the subscriber does not currently have “originating” unregistered services. In a second solution implemented in the first embodiment of the invention, if the subscriber is not registered to the IMS, then the home subscriber server always provides the Server-Capabilities AVP in a location information response message, even if the subscriber does not have current unregistered services.
In a second embodiment of the invention, the application server sends the request to the I-CSCF and inserts a public identity of the subscriber in a P-Asserted-Identity header, as required by the disclosure of clause 5.7.3 of the 3GPP 24.229 specification. The application server indicates to the I-CSCF that this is an originating request. I-CSCF, recognizing that the originating request is being served, queries the home subscriber server for capability information for the subscriber indicated in the P-Asserted-Identity header of the SIP request. That is, I-CSCF sends the location information request message to the home subscriber server through a Cx interface using the identity from P-Asserted-Identity header, instead of a Request-URI as in a terminating case, to the Public-Identity AVP of Cx message. When the I-CSCF receives a response from the home subscriber server in the location information answer message, the I-CSCF either sends the request to the default S-CSCF or selects a S-CSCF based on the capabilities according to normal procedure. I-CSCF indicates in the SIP message that the S-CSCF should serve the request as an “originating” request, by placing an ORIG parameter to URI of S-CSCF. Alternatively, when the application server sends the SIP request to the I-CSCF, the application service adds and ORIG parameter to the URI of the I-CSCF that is added to the SIP message as the topmost route header.
Even in the second embodiment of the invention, the I-CSCF indicates to the home subscriber server in the location information request message that a location information query is being made for the originating request. If the subscriber, in this embodiment, is not registered to the IMS, then in a first solution implemented in the second embodiment, the home subscriber server provides Server-Capabilities AVP in a location information response message, for such location information request message that includes an indication of the originating scenario, even if the subscriber does not have “originating” unregistered services. In the second solution implemented in the second embodiment of the invention, if the subscriber is not registered to the IMS, then the home subscriber server always provides the Server-Capabilities AVP in a location information response message, even if the subscriber does not have unregistered services. To implement the second solution, no extensions of Cx messages are needed, as the only change is in the home subscriber server's behaviour. No change is also needed in the I-CSCF procedures of handling the location information answer messages, thus this solution is backward compatible for I-CSCF.
One possible method for implementing the second embodiment of the invention is for the application server to indicate an originating scenario to the I-CSCF by putting the ORIG flag as a URI parameter in a Request-URI of SIP message. The Request-URI of SIP message is parsed by the I-CSCF according to normal I-CSCF procedures. If this method is used, then the I-CSCF removes the ORIG flag from the Request-URI of SIP message.
In the second embodiment, operators may define a dedicated I-CSCF (configured in application servers) that serves only originating requests for unregistered services and that does not have S-CSCF selection based capabilities. In the application server, is must be ensured that the I-CSCF supports this functionality.
Another possible implementation method of the second embodiment is to define a new SIP header or define a new parameter for the P-Asserted-Identity header, which includes an identifier of the subscriber. If this method is chosen, then the I-CSCF has to parse the additional SIP header as part of its normal procedure in order for it to decide if the originating request is being served. The location information request message of the Cx interface should be extended with a new AVP that includes an indication of whether the location information request is made for an originating request. The new AVP may be optional, thus an I-CSCF not supporting the extension of the Cx interface may still work with this solution. Another alternative is to extend the existing Public-Identity AVP with the information on whether a location information query is requested for the originating request.
The first embodiment requires that the S-CSCFs addresses and the capabilitites supported by those S-CSCFs are configured to each application server that would like to originate requests on behalf of a subscriber. Also, the same S-CSCF selection logic is implemented to each application server, otherwise already available in the I-CSCF. With the first embodiment, one less role is involved in processing of originating requests and no modification is needed to the SIP. However, configuring S-CSCF information to the applications server might not be preferred by operators due to trust issues.
The second embodiment relies on the I-CSCF's existing capability for the S-CSCF selection. No additional configuration is needed for the application server, no capability based S-CSCF selection is needed in the application server, although change is required in the SIP protocol and in I-CSCF behaviour. The first solution implemented in the first and second embodiments requires introduction of new AVP or change of existing Public-Identity AVP to the location information request Cx message. In this solution, change is required both in the I-CSCF and home subscriber server implementation, thus this solution is not backward compatible for the I-CSCF and home subscribe server. The second solution implemented in the first and second embodiments does not require change in the Cx message; it only requires change in the home subscriber server's implementation; thus, this solution is backward compatible for the I-CSCF.
It should be appreciated by one skilled in art, that the present invention may be utilized in any device that implements the network availability information described above. The foregoing description has been directed to specific embodiments of this invention. It will be apparent; however, that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advantages. Therefore, it is the object of the appended claims to cover all such variations and modifications as come within the true spirit and scope of the invention.
This application claims priority of U.S. Provisional Patent Application Ser. No. 60/795,582, filed on Apr. 28, 2006 and U.S. Provisional Patent Application Ser. No. 60/838,899, filed on Aug. 21, 2006. The subject matter of the above referenced applications is incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60795582 | Apr 2006 | US | |
| 60838899 | Aug 2006 | US |
