1. SIP and IMS Enabled Residential Gateway Sergio Romero Telefónica I+D Jan Önnegren Ericsson AB Alex De Smedt Thomson Telecom

2. 2 www.ist-muse.eu Index  Introduction  Existing issues  SIP & the CPN  3GPP vs IETF SIP  Proposed architecture  SIP B2BUA  Auxiliary file and DBs  Complete architecture  Functional examples  Conclusions

3. 3 www.ist-muse.eu Introduction  IP multimedia services are becoming more and more demanded by residential users. Within this scenario:  SIP protocol has been designed for controlling IP multimedia sessions and is talented to replace previous signalling protocols like H.323 or the aged SS7  IMS has been presented as the framework able to provide a better service provisioning and control for IP multimedia services in a NGN architecture  the CPN needs to be “SIP&IMS-friendly”

4. 4 www.ist-muse.eu Existing issues – SIP & the CPN  Legacy terminals do not support SIP  Legacy terminals (e.g. POTS or DECT phones) need a terminal adapter to translate dated signalling protocols and to act as SIP UA  Private IP addressing at the CPN  NA(P)T binding mechanisms at the RGW do not take into account that SIP messages take transport address information in their payload. To provide an effective NA(P)T traversal solution other techniques must be applied (e.g. STUN, ICE, or ALG)  Traffic blocking at the RGW  Firewall at the RGW needs to be configured to open signalling and media ports (e.g. 5060/UDP for SIP signalling and 8000/UDP for RTP media)

5. 5 www.ist-muse.eu Existing issues – 3GPP vs IETF SIP  SIP profile  3GPP specifies a greater number of compulsory messages  3GPP requires a greater number of compulsory headers and has its own private headers (P-Headers)

6. 6 www.ist-muse.eu Existing issues – 3GPP vs IETF SIP  Identities and security mechanisms  3GPP terminals require an ISIM application that stores public identities (IMPUs), but also the private identity (IMPI) and the authentication key that are used during the complex Digest AKA mechanism. IETF RFCs only provides an HTTP Digest based authentication mechanism  3GPP uses IPsec ESP to provide integrity and confidentiality between the terminal and the IMS core. IETF RFCs do not cover the establishment of any kind of SAs

7. 7 www.ist-muse.eu Proposed architecture – SIP B2BUA  Definition  A B2BUA is a signalling control and handling entity that after receiving a SIP request/response can reformulate and send it out as a new request/response according to some given rules  A SIP B2BUA is able to manage and monitor the entire session state and parameters

8. 8 www.ist-muse.eu Proposed architecture – SIP B2BUA  NA(P)T and firewall support  For signalling flows, a B2BUA can change when necessary the IP addresses and ports in the incoming or outgoing SIP messages  For media streams, a B2BUA can interact with the NA(P)T mechanism to provide the required bindings  In both cases, a B2BUA can ask the firewall to open the required ports  QoS assurance  The B2BUA can obtain from the SDP payload what codecs are going to be used in a multimedia session and interact with the CAC to check if there are enough resources to support the session

9. 9 www.ist-muse.eu Proposed architecture – SIP B2BUA  SIP interworking  The B2BUA can generate, drop or modify different SIP messages in order to provide the required interoperability between a 3GPP network and those SIP UAs located at the CPN that only can understand the simpler IETF SIP profile  The B2BUA is able to use the information stored in an ISIM to be authenticated against the IMS network and it also can establish the required SAs  Multimedia PBX  The B2BUA can forward any SIP message at any time according to some rules. Hence, it is able to route all the incoming and outgoing SIP calls as a traditional PBX

10. 10 www.ist-muse.eu Proposed architecture – Routing File  Routing File  Rules to control the multimedia sessions that are managed by the RGW. According to them, the B2BUA decides how outgoing or incoming sessions must be routed

11. 11 www.ist-muse.eu Proposed architecture – Auxiliary Databases  Credentials DB  Local credentials that must be used at the registration to authenticate home users against the B2BUA  Location DB  Location information (bindings of contact addresses and SIP URIs) used by the B2BUA to route the messages

12. 12 www.ist-muse.eu Proposed architecture – Auxiliary Databases  Service DB A.General B2BUA parameters like status, supported SIP methods, etc. B.SIP and IMS services parameters like servers addresses, listening ports, global credentials, etc. This DB can be remotely managed via TR-069 by extending TR-098 data model InternetGatewayDevice.B2BUA. SIPService.{i}. Service parameters required for accessing a concrete SIP service GlobalAoRUser's identity for the corresponding SIP network. This address will be included in the location database of the service provider. AuthenticationMethodHTTP Digest authentication or none authentication required for accessing the service provider network. Values: “None”, “Digest” Default: “Digest” DigestUsernameUsername for digest authentication. DigestPasswordPassword for digest authentication. RegistrationPeriodPeriod over which the registration must be refreshed, in seconds. RegisterExpiresRegister request Expires header value, in seconds. ProxyServerHost name or IP address of the SIP proxy server. ProxyServerPortDestination port when connecting to the SIP proxy server. Values: [0,65535] Default: 5060

13. 13 www.ist-muse.eu Proposed architecture – Signalling handling  SIP/IMS Handling and Control  Routing & Control module modifies the SIP signalling (according to the routing rules), and can interact with the CAC, the NA(P)T and the Firewall  SIP/IMS Interworking module adapts different SIP profiles and uses the IMS identities (IMPI and IMPUs) and the key stored in the ISIM

14. 14 www.ist-muse.eu Proposed architecture – General scenario

15. 15 www.ist-muse.eu Functional examples – IMS registration

16. 16 www.ist-muse.eu Functional examples – IMS session

17. 17 www.ist-muse.eu Conclusions  The proposed architecture pushes the incorporation of the CPN to the IMS/NGN...  It contributes to ensure the viability of the multimedia sessions interacting automatically with other blocks of the RGW  It provides a total control of the ongoing multimedia sessions to the RGW administrator  It is able to adapt the signalling and the security mechanisms to fulfil 3GPP requirements