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 220.127.116.11
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 18.104.22.168.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 22.214.171.124.3, postulate 5C, remove any P-Preferred-Identity headers if present.
28. Clarification in postulate 6 of section 126.96.36.199.3.
29. P-CSCF procedures, section 188.8.131.52.11, postulate 2A now asks to remove P-Preffered-Identity header if present
30. Clarifications for postulate 3 of section 184.108.40.206.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 220.127.116.11.4, P-CSCF now has to remove any P-Preferred-Identity header if present. This is an extra check now.
33. Postulate 3, section 18.104.22.168.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 22.214.171.124.8 postulate 1A.
35. Clarification that the P-CSCF needs to support draft-ietf-sip-outbound in addition to 3261 for section 126.96.36.199.8 while deciding upon the forwarding the request to the UE.
36. Major refactoring additions of the procedures for the P-CSCF in section 188.8.131.52 postulate 1A. Some 3-4 checks have been added.
37. Refactoring of point 3 of section 184.108.40.206. 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 220.127.116.11, 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 18.104.22.168. 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 22.214.171.124.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 126.96.36.199 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 188.8.131.52, 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 184.108.40.206.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.