Race Condition for “tel” URI Routing in IMS – Unknown numbers !

Recently, in a discussion I came across a race condition that occurs in IMS for routing tel URIs which no longer exist in the IMS domain (operator’s network).

The problem statement is as follows:

When the operator de-provisions a telephone number from the IMS core, and another IMS subscriber dials this invalid number, then the call traverses the Proxy CSCF and hits the S-CSCF. I am assuming that it is an intra IMS domain call – synonymous to a local call. Here the called party (B-party) is the invalid subscriber. The S-CSCF executes the originating iFC set for the calling party as per the standards. Then, the S-CSCF realizes that the called party address is a tel URI and an ENUM query needs to be performed. As the subscriber has been de-provisioned from the network completely, the ENUM query fails.

This triggers the S-CSCF to forward the call to BGCF believing that legacy interconnect procedures need to be performed and the called party is a legacy subscriber. The BGCF attempts breakout towards the MGCF, which converts it to an IAM and sends it to the PSTN.

The situation would become even more complex with number portability, where we can no longer filter numbers based on ranges alone at the BGCF.

The PSTN domain would send it back to the IMS core thinking that the call was destined towards IMS. As inter-working will take place again at the MGCF for the incoming call leg, this call would land as a brand new call to the I-CSCF (with a refreshed Max-Forwards header) and a new Call-id.

Now, the I-CSCF will perform the DIAMETER user location query to the HSS and this query would fail, as the tel uri never existed in the first place. Based on the procedures in TS 24.229, the I-CSCF will inspect the address (which is the tel URI) and then perform the ENUM query. This query would fail as expected and the call will be forwarded to the BGCF once more mistaking it to the legacy interconnect case.

The sequence of events above would lead to an infinite loop in the network for this call.

Solution:

The solution to this problem is to avoid the breakout to the PSTN through the BGCF in case the user has dialed an invalid number. In order for this to happen, the ENUM query must not fail. Hence, it is proposed that when the user is de-provisioned from the network, the ENUM mapping of his number is changed to a generic SIP URI such as the following -

sip:doesnotexist@domain

This will ensure that this generic SIP URI is returned when the ENUM query is fired. In this case, the S-CSCF will forward the call to the I-CSCF instead of the BGCF. The I-CSCF will then forward the call to the MRFC by executing PSI subdomain routing in the sense of TS 23.228.

This would ensure that the MRF will play an announcement that the “number does not exist”. This is what is needed in this scenario. But, even here, the I-CSCF needs to do some NETANN magic before forwarding the call to the MRF (refer here: http://tools.ietf.org/html/rfc4240). Hence, the I-CSCF implementation has to be careful to make this work well.

 

As and when I come across more race conditions in the IMS network, I will post them here (most probably with a possible solution to get around them).

 

IMS User Data Convergence (UDC) and its harmonization with 3GPP GUP

1. Introduction:

In the IP Multimedia Subsystem, data pertaining to the subscriber is managed by different network entities. Network entities maintain role-specific data. This means that the data maintained at the network element satisfies the use cases of that network element only and helps in its proper functioning.

These network entities belong to different telecom planes in the context of network deployment. Some of these entities belong to the signaling plane, some belong to the OSS/BSS plane, others may belong to the services plane and some may be part of the policy/QoS plane.

Therefore, the nature of the data maintained at each telecom tier is specific to the functions it has to perform. There may or may not be a logical/functional linkage between the data fragments belonging to these diverse planes.

However, there are instances where this diverse data has cohesions with respect to each other and there is room for optimized data storage.

Sometimes, it becomes necessary to synchronize the data maintained at different planes. This is usually observed during certain provisioning scenarios.

In order to meet these challenges, and to improve data management and promote optimized storage of data, 3GPP has proposed two central concepts of data management:

1. The 3GPP Generic User Profile (GuP), which represents a uniform and generic data representation paradigm for the IMS subscriber’s data.

2. User Data Convergence (UDC), which presents an alternative architecture for optimized data storage for IMS network elements keeping in mind the challenges of scalability and  redundancy.

This post aims to harmonize these two central concepts to present a unified strategy for IMS data management exploiting the benefits of both these concepts (GuP and UDC).

In addition to subscriber-specific data management, this post also explores possible solutions for maintaining IMS network element specific data by using the concepts of GuP and UDC.

2. Types of User Data in a (telecom) IMS network

The nature of data stored in an IMS network, or in any telecom network can be broadly divided in the following categories:

a. Subscriber specific user profile data

b. Device specific data

c. Service specific data

d. QoS and Policy specific data

e. Charging specific data

f. Provisioning and OSS specific data

g. Access-network specific data

h. IMS network element specific data.

There may me more categories and sub-categories in addition to those defined above. However, these are the “major” data types that are encountered during practical deployment.

The first six categories (a-f) pertain to the data maintained for the customer.

The last  two categories (g-h) are maintained at the individual IMS network elements. This type of data may be regarded as internal configuration data that enables the proper functioning of the network element. This data may also be stored in north-bound management entities (EMS and NMS systems).

Conceptually speaking, the figure shown below summarizes the scope for this post and demarcates the nature of the IMS data that needs to be maintained in a real network:

3. Current Data management situation across telco planes:

Data management in the IP Multimedia Subsystem (IMS) is distributed amongst network elements.

– When the subscriber is provisioned in an IMS network for the first time, a subscriber user profile is created in the HSS. This data is maintained in the HSS for as long as the subscriber is part of the IMS network.

– If the subscriber opts for certain value added services, data pertaining to such services is maintained in the individual application servers that host the VASs. Some IMS networks also have a Service Delivery Platform (SDP) deployment that is a logical aggregate of SIP application servers. Hence, the data relating to services opted by the subscriber is maintained at the services tier.

– Each subscriber has to be charged and billed for his services based on the tariff plans opted by the subscriber. Charging specific data and the tariff plan related information is maintained at the charging system. The charging system caters to both post-paid (CDF) customers and pre-paid (OCS) customers. This charging profile is used for creating Charging Detail Records (CDRs) when the subscriber consumes his/her services in the IMS network. These CDRs are fed to the billing system (BSS) for the generation of itemized bills.

– As the IMS core network is access independent, an IMS subscriber may own multiple devices that use different access networks to connect to the core network and its services. A subscriber may use Mobile WiMAX to access his data services and video share services. The subscriber may use a mobile handset (HSPA enabled) to access his Presence and presence-enabled services. A set top box may be used for accessing IPTV and triple play services and so on.

Access network based information is stored at the PCRF, HSS and Session Border Controllers (SBCs).

The IMS core network has to store certain information pertaining to these diverse access networks for the following reasons:

a. For providing proper Quality of Service based on the access network being used. Eg: HSPA and Fixed broadband customers shall enjoy GOLD class QoS. However, GPRS and WLAN based customers will be entitled to SILVER class QoS due to the inherent limitations of these networks.

b. For applying access network based policies at the network elements. Eg: If the access network of the customer is Fixed broadband, then the S-CSCF needs to forward all requests unconditionally to an IPTV Application Server.

c. For applying the appropriate charging strategy based on the access network in use. Eg: IPTV based Video on Demand can be charged based on the volume of data downloaded. However, Presence based services may be charged on a monthly basis.

– Device profiles of IMS User Equipment can be stored in an OMA compliant Device Management server. This server can also be used for OTA updates and provisioning actions. Specialized device information such as the contact book, buddy lists and personal network management information can be stored in their respective application servers over the Ut interface.

– OSS information pertaining to the subscriber has to be maintained at provisioning platforms, such as those defined by the NGoSS body. A subscriber may have logged many active requests and queries to the OSS system. These requests are executed by business processes modelled by using BPM (Business Process Management) tools and they frequently require offline action by the carrier. In the meanwhile, the business process related data has to be maintained at the OSS platform until the requests are closed by the operator and the requests are resolved.

In addition to this data, there are special data types that are consumed by the IMS core network for its internal functioning.  Some examples of this data are given below:

a. CSCF internal configuration data (static and runtime)

b. CDRs (at the CDF to be pushed to the BSS)

c. FCAPS data (at the SNMP agent of the NE)

d. Persistent storage data of the CSCFs/HSS (for IMS restoration and HA)

e. Media files of the MRF (announcements, tones etc)

f. EMS/NMS configuration data. (topology graphs, NE information)

g. OSS Data (customer care requests, eTOM module related data)

The following table provides a bird eye’s view on which network entity maintains which data type:

4. The concept of the UDC architecture

4.1 Concepts:

User Data Convergence (UDC) aims to address the siloed approach of data management across telco planes and network entities. In the current data management scenario, data is managed individually by network elements in their own closed repositories. This approach of data management gives rise to rigid data silos.

When scaling the network, the number of network elements also increase. This leads to further fragmentation of user data amongst multiple instances of the same logical application.

Eg: For supporting 3 million BHCA, if we deploy 3 HSS instances in the same domain, then effectively user data of that domain is being maintained at three separate locations, even though the data access function (HSS) is the same logical application.

This siloed approach is logically represented as shown in the figure below:

With the advent of IMS and IMS based services, data management at several places poses a major operational and maintenance issue. Introduction of new user data becomes an issue, as any new user data attribute needs to be reflected at multiple locations. Moreover, data synchronization across multiple locations becomes a major challenge.

4.2 UDC Deliverables:

Therefore, UDC aims to provide the following deliverables:

a. To simplify overall network topology and interfaces

b. To overcome the data capacity bottleneck of a single entry point

c. Avoid data duplication and inconsistency

d. Avoid data fragmentation

e. Reduce CAPEX and OPEX for the carrier.

Therefore, UDC aims to provide convergence of user data in order to enable smoother management and deployment of new services and networks.

A logical view of UDC deliverables can be represented as shown in the figure below:

4.3 UDC Architecture:

This section will provide an introduction to the UDC architectural model and its major interfaces.

The architecture consists of the following major components:

a. Client applications.

Client applications may be IMS clients, XDM clients, SIP based application servers or PC browsers.

b. Application Front ends.

The application front ends are functional entities, such as the HLR/HSS/AUC, Application Servers, Access Network Discovery and Selection Function in Home Network (H-ANDSF), any other Core Network nodes, Provisioning system, etc.

When the UDC architecture is applied, application front ends keep the application logic, but they do not locally store user data permanently. These data-less functional entities are collectively known in the UDC architecture as Application Front Ends.

There is a special Application front end for the UDR which is used as a provisioning application for it. It is called a Provisioning Front End. The Provisioning Front End is defined as an Application Front End for the purpose of provisioning the UDR. The Provisioning Front End provides means to create, delete, modify and retrieve user data.

c. User Data repository.

The User Data Repository (UDR) is a functional entity that acts as a single logical repository that stores converged user data. The user-related data that traditionally has been stored into the HSS /HLR/AuC, Application Servers, etc., is now stored in the UDR according to a UDC information model. UDR facilitates the share and the provisioning of user-related data throughout services of 3GPP system.

UDR provides a unique reference point to one or more Applications Front Ends, such as: one or more HSS/HLR/AuC-FEs, and one or more AS- FEs. The reference point is named Ud. UDR shall provide support for multiple applications simultaneously.

Applications that are 3rd party or are outside the trusted domain of the IMS network can access the UDR after proper authentication and authorization procedures have been applied.

The diagram below shows this architecture:

The Ud reference allows different FEs to create, read, modify and delete user data stored in the UDR.

The Ud reference point also supports subscriptions/notifications functionality which allows a relevant FE to be notified about specific events which may occur on specific user data in the UDR.

The events can be changes on existing user data, addition of user data etc. All these operations are ACID compliant (Atomicity, Consistency, Isolation, and Durability).

5. The concept of the GUP architecture:

Conceptually speaking, the GUP is a 3 tier architecture. It consists of client applications, the GUP server and the data repositories.

The key objective of having this architecture is to have a harmonized means of data access for a particular user. A user may have data relating to his services, charging policies, QoS metrics and HSS profile data, all of which is maintained separately by these entities. Each entity would also have its own unique semantics of data storage.

The GUP provides a common mechanism of data addressal, reference, access and modification to all applications that may need this data for their functioning. GUP data may be stored at one place, or it may be stored with different entities. However, the data access and manipulation semantics shall comply to the GUP architecture. This will allow uniformity with regard to the management of the subscriber’s data.

The suppliers and consumers of the data can be divided into the following groups of applications:

-     Applications in the home network.

-     3^rd Party Applications.

-     OAM and subscription management applications.

The Generic User Profile architecture is composed of the following major components and interfaces:

a. GUP Server:

The GUP Server acts as a single point of access of subscriber data. The physical location of the GUP server is implementation dependant and the standard does not impose any special requirements. The GUP server acts as a single  interface which is  exposed to the client applications who wish to manipulate the subscriber data.

The GUP server can act in two modes, namely proxy mode and redirect mode. While operating in proxy mode, all requests made to the GUP server are proxied  to the appropriate data repositories. The results of those queries are returned back to the application by the GUP Server.

While operating in redirect mode, the GUP server redirects the client application to the actual GUP repositories that contain the data which was requested initially by the client.

The interface between the client applications and the GUP server is the Rg reference point.

b. Repository Access Function (RAF):

The RAF behaves as an abstraction between the GUP server and the GUP data repositories. It hides the actual implementation of the data repository from the server. The interface between the GUP server and RAF is the Rp reference point.

c. GUP Data Repositories:

The data repositories store the master copy of one or more GUP data components.

d. Rg and Rp reference points:

These are the two major reference points in the GUP architecture. The clients share the Rg reference point with the GUP server. The protocol on this interface is SOAP (Simple Object Access Protocol) which is exposed as a web service to the clients.

The GUP server has the Rp reference point towards the RAF. This reference point is implementation dependant. However the standard shows a SOAP interface on this interface

The Rp reference point shall allow the GUP Server or applications, excluding external applications (e.g. located in a third party application or in the IMS UE), to create, read, modify and delete user profile data. Rp is an intra-operator reference point.

e. Client Applications:

These are the application servers and applications that need access to GUP data components. They may host some GUP data components themselves and may act as RAFs.

The physical architecture of the GUP arrangement is shown below:

6. Harmonizing UDC with the GUP architecture:

These two architectural options provided by 3GPP can be harmonized and used together to achieve a cohesive strategy for data management and access.

While UDC provides a common data management and access architecture, GUP provides a means of locating and addressing that data using a common strategy.

This section will provide a unified architecture that leverages upon the concepts of UDC and GUP to provide a unified data management strategy in an IMS network.

6.1 Unified architectural view (GuP+UDC):

A unified view of the integrated Generic User Profile architecture with the User Data convergence paradigm is shown below:

The unified architecture will consist of the following  concepts:

a. The client applications

These are the applications which act as consumers of the data. The data being referred to in the unified architecture is the GUP data fragments. The GUP data is being stored in GUP repositories that form parts of the User Data repository (UDR).

b. The Rg reference point re-use for UDC:

For applications that wish to access the UDR over a proprietary interface (labelled as “other ref points” in the UDC standard) shall use the standardized Rg reference point that follows the SOAP/WSDL standard semantics over HTTP. Client applications such as Web 2.0 applications, OSS entities and self care portals can use the Rg reference point to access the UDR.

c. Partial standardization of the Rp reference point for intra operator entities:

The Rp reference point allows entities belong to the same home network to directly access the user data from the RAF. Therefore, SIP application servers will access the user data over the Sh interface from the HSS belonging in the same network. However, if it needs to modify data that is outside the scope of the Sh XML schema, it will need to send the request to the GUP server over SOAP giving instructions to execute one of the standard procedures over the Rg reference point (Create,Modify, Delete etc). These procedures will be mapped to their appropriate counterparts over the Rp reference point.

d. RAFs integrated with Application Front Ends (FEs):

Application front ends of the UDC architecture will behave as RAFs for their respective GUP components. These RAFs will support both standard interfaces (as described in point c) and SOAP based Rp interfaces.

e. GUP data repositories integrated with the UDR:

The UDR will now be composed of GUP data repositories. However, there may be instances where the data model of certain GUP components require a separate data repository. In such a case, the GUP repository will be outside the UDR. The location of this distributed GUP component will be resolved by the GUP server by locating the appropriate RAF component.

f. Ud interface between integrated RAF+FEs and UDR:

The Ud reference point will be re-used as an interface between the integrated RAF+FEs and the actual UDR (or independent GUP repository).

6.2 Case Study: HSS IMS GuP Components:

The following figure  gives an outline of the UML model of the logical view of the HSS IMS GUP Components. The main Component is called HSSIMSData.

Each element in that figure represents a part of the XML Schema structure, either a GUP Component or a lower level block of data contained in a GUP Component. Elements marked with the same background colour make up an independently manageable GUP Component, whose root is marked with ‘<<GUP Component>>’.

All HSS IMS GUP Components can be managed with the procedures provided by GUP.

(Click on the image for a larger view)

7. User Data access scenarios:

Please refer to the unified architecture described in Section-6 for realizing these use cases.

7.1 Typical IMS use case:

In this use case, the S-CSCF requests data over DIAMETER protocol from the HSS to execute its duties during IMS registration. Here the Rp interface is nothing but the standard Cx interface.

7.2 OSS entity use case:

In this use case, the service activation eTOM of the OSS system activates the service of a particular subscriber by invoking an operation in the IMS HSS. Here the interface under use is the Rg interface over SOAP protocol.

7.3 SIP-Application server use case

In this use case, a SIP application server retrieves data from the HSS regarding the barring status of an IMS public user identity before executing its service logic along with the repository data stored in the HSS. The repository data is retrieved over the Rp interface, which is nothing but the Sh interface. However, the barring indication information is taken over the Rg interface.

7.4 IMS enablers use case:

A Click-to-Call application fetches the buddy list of a subscriber who has just logged into the server over the standard Rp interface that uses XCAP protocol towards the XDM server. The same application then subscribes to the presence status of each buddy present in the list over SIP protocol.

7.5 Web 2.0 use case:

A Web 2.0 application requests the subscriber’s presence information from the Presence Server and his/her photograph from a Flickr application repository. After the presence data has been fetched, this application retrieves the implicit IMPU set from the HSS. Then this application fetches the location of each of the registered public user identities.

All this information is then rendered on a Google Map application complete with presence status and a photograph thumbnail.

7.6 Self help portal use case:

The subscriber requests to subscribe to the voicemail service over a self help portal. On accepting the agreement, the Self help portal sends a trigger to the charging platform to deduct the amount suitable for this service and executes a create procedure towards the HSS to create an iFC component (The ServiceProfile <<GUPComponent>> defined in the standards). This operation takes place over the Rg interface.

8. Conclusion:

It is feasible to integrate and leverage upon the strengths of the User Data Convergence (UDC) architecture in cohesion with the Generic User Profile (GUP) semantics to derive a hybrid data management strategy.

However, the final reference architecture can be derived only when the concrete use cases to be supported are known.

A unified architecture will make data management and data access more intuitive and re-use the standardization principles wherever possible as demonstrated in Section-6.

3GPP IMS Release-9 Highlights and Changes.

3GPP IMS Release- 9 has been around for some months now.

From the IMS core network perspective, there have been certain additions and modifications to the procedures given in TS 24.229.

This specification acts as the ‘bible’ for any vendor wishing to implement IMS. This specification also changes and updates itself very frequently and usually comes with scores of additions and modifications in its quarterly minor releases.

Some of the major highlights of Release 9 are discussed.

The current release at the time of this post is 9.1.0 which is being discussed here.

As these changes are very low-level and implementation specific, it seems that there is still heavy refactoring going on in 3GPP for aligning the procedures for IMS and coming out with a stable set of procedures (atleast for the core network entities).

Such changes can be very difficult to spot and implement from the developer’s perspective.  Some changes given below can even force you to modify some of your use cases. Personally speaking, it becomes very frustrating when the procedures change so frequently. Atleast, there should be no changes/bugs in the core procedures of the IMS nodes.

IMPORTANT NOTE: Read on at your own risk. Not for the weak at heart.

Highlights, Changes and Additions:

1. Clarification in UE procedures for sending requests on protected ports to the P-CSCF regarding subsequent registration requests.

2. Addition and clarification in UE procedures regarding the usage of the ‘outboud’ parameter in the Supported header. It also includes a check whether the ‘reg-id’ and “+sip.instance” Contact header field parameters are present in the 200 OK of the REGISTER request.

3. Elaboration on the decision making of the UE regarding the S-CSCF behavior,  if the ‘outbound’ parameter was not present in the 200 ok for the REGISTER.

4. A note providing an implementation option to the UE in case Timer F expires at the SIP Stack.

5.  Change of procedures on the number of REGISTRATION attempts by the UE and in case of failure, the procedures that follow it (exception handling).

6. Removal of procedures at the UE that needed a check for Retry-After header for re-attempts for Registration.

7. Removal of procedures at the UE (2 postulates) when it sends a SUBSCRIBE to the network.

8. Removal of a check at the UE for sending a SUBSCRIBE for the debug event package.

9.  Addition of a postulate for generic procedures except the REGISTER request handling where now the protected port has to be added by the UE in the Contact header.

10. Refactoring of the abnormal exception handling use cases at the UE when it receives 504 error response.

11. Refactoring of procedures for emergency call handling at the UE and parsing responsibilities of the 3GPP IMS XML file received from the network

12. Additional responsibility at the UE to advertize support for draft-ietf-sipcore-keep for emergency IMS sessions.

13. Major refactoring on pages 92 and 94 regarding the interpretation of certain XML elements for emergency sessions initiated by the UE when it was registered using non-emergency registration procedures.

14.  Clarification note in P-CSCF procedures regarding protected ports in section 5.2.2.1

15.  P-CSCF procedural support for draft-ietf-sip-outbound, and addition of the ‘ob’ parameter in the SIP URI.

16. P-CSCF procedural support for draft-ietf-sipcore-keep

17. Clarification on point 6 for P-CSCF registration procedures when the request needs to be sent to an I-BCF

18. Change in point 7 of P-CSCF registration procedures in case the request has to be sent to the I-CSCF

19. Clarifications in points 8 and 9 of P-CSCF registration procedures while dealing with a UE behind a NAT and alignment with draft-ietf-sipcode-keepalive.

20. P-CSCF can now not close the TCP connection with the UE in case it has been detected to be behind a NAT !

21. P-CSCF can add the “received” parameter and the “rport” parameter in case SIP Digest without TLS is being used as the security mechanism with that UE.

22. Additional check at the P-CSCF in case SIP Digest WITH TLS is being used, that the FQDN in the Contact header resolves correctly to the IP Address bound to that TLS session. Here the P-CSCF will perform a reverse DNS query !

23. P-CSCF has to check whether there is an I-BCF in the network while sending out SUBSCRIBES to reg event packages. If there is no I-BCF, do a DNS lookup and send it to the I-CSCF, else send it to the I-BCF.

24. Major refactoring of procedures for the P-CSCF for general request handling in Section 5.2.6.3.1

25. Inspection of the host portion of the sent-by field of the Via header received from the UE at the P-CSCF. Check whether the IP address given there differs from the source IP from where the packet was originally received. Also add the UEs protected server port over there.

26. P-CSCF abnormal cases postulate (a) asks it to add some elements of the 3GPP IM CN subsystem XML body while sending an error response.

27. P-CSCF procedures, initial request for a dialog handling procedures, Section 5.2.6.3.3, postulate 5C, remove any P-Preferred-Identity headers if present.

28. Clarification in postulate 6 of section 5.2.6.3.3.

29. P-CSCF procedures, section 5.2.6.3.11, postulate 2A now asks to remove P-Preffered-Identity header if present

30. Clarifications for postulate 3 of section 5.2.6.3.11

31.  P-CSCF procedures for generic response handling now require the inspection of the rport and received parameters before sending out any responses to the UE.

32.  In section 5.2.6.4.4, P-CSCF now has to remove any P-Preferred-Identity header if present. This is an extra check now.

33. Postulate 3, section 5.2.6.4.4, P-CSCF needs to remove the “comp” SIP URI parameter from the Record-Route header.

34.  P-CSCF needs to remove the P-Preferred-Identity field in section 5.2.6.4.8 postulate 1A.

35. Clarification that the P-CSCF needs to support draft-ietf-sip-outbound in addition to 3261 for section 5.2.6.4.8 while deciding upon the forwarding the request to the UE.

36.  Major refactoring additions of the procedures for the P-CSCF in section 5.2.10.3 postulate 1A. Some 3-4 checks have been added.

37. Refactoring of point 3 of section 5.2.10.3. Point 3 has been changed to align towards draft-ietf-sipcore-keep. So this postulate needs to be re-implemented.

38. Inspection and addition of the 3GPP IMS XML schema elements in section 5.2.10.4, postulate OA, points II and IV.

39.  Major major refactoring, removal and additions in the procedures of the P-CSCF in points 1, 1A, 2 and 3 of section 5.2.10.4. Almost everything has been modified here ! Reimplementation required.

40.  P-CSCF abnormal exception handling procedures aligned to the processing of the 3GPP IMS XML body.

41. S-CSCF procedures for initial registration have to inspect the P-Access-Network-Info header to decide the authentication scheme to use for the UE.

42. S-CSCF procedures for receiving an unprotected register request additions to handle the REGISTER from an MSC enhanced ICS node.

43. S-CSCF derivation of IMPI for NASS IMS bundled authentication in case  the Authorization header is missing.

44. S-CSCF inspection of the “reg-id” parameter, the “ob” parameter and the “outbound” parameter in case of IMS AKA authentication, and sending of a 439 response.

45. S-CSCF procedures section 5.4.1.2.2, point 11 has almost been scrapped and the earlier checks removed.

46.  Digest URI need not match the SIP URI in case a reg-await-auth timer is running and SIP Digest is the mechanism used at the S-CSCF for authentication.

47. Inspection of the Authorization header to contain the “auth-done” parameter at the S-CSCF.

48. Clarification for the <ims-3gpp> element in 3rd party registration procedures.

49. Check for P-Served-User header in S-CSCF procedures section 5.4.3.2 and associated procedures if its not present.

50. Addition of the P-Asserted-Identity header in the 504 response at the S-CSCF and the <ims-3gpp> element as well in the body.

51. Section 5.4.3.3, points 10 a and 10d of S-CSCF procedures have undergone major additions and refactoring. Re-implement it.

52. Removal of authentication parameter checks in point 3 section 5.4.3.6.1 of the S-CSCF procedures.

I hope you all enjoyed this list. What it does to the developer is, that you go in a forced fixing loop and your focus goes away from adding more features…..to fixing existing ones and aligning them to the standard !

I just hope that we do not get a list of such major changes in the procedures in the next incremental release.

Please note, that these changes only account for those in the procedures of the UE, P-CSCF and S-CSCF. I-CSCF was fortunately untouched in this 3GPP Release. There might be many more changes in the procedures of other nodes such as the BGCF, MGCF, I-BCF, E-CSCF etc…which i have not listed here.