1 / 7

SIPPING 3GPP Requirements Ad Hoc Meeting Georg Mayer IETF#53, Minneapolis

SIPPING 3GPP Requirements Ad Hoc Meeting Georg Mayer IETF#53, Minneapolis. SIP – the Solution for IMS. Loose Routing adopted All IMS entities that forward SIP messages support loose routing P/S-CSCF’s are transparent B2BUAs (e.g. network initiated call release, header removal by P-CSCF)

ronli
Download Presentation

SIPPING 3GPP Requirements Ad Hoc Meeting Georg Mayer IETF#53, Minneapolis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SIPPING 3GPP Requirements Ad Hoc Meeting Georg Mayer IETF#53, Minneapolis

  2. SIP – the Solution for IMS • Loose Routing adopted • All IMS entities that forward SIP messages support loose routing • P/S-CSCF’s are transparent B2BUAs (e.g. network initiated call release, header removal by P-CSCF) • Max-Forwards adopted • DTMF via RTP (RFC2833) • manyfolks-05 & update drafts – adoption still under discussion • Path Header – needs further discussion (also in IETF)

  3. Loose Service Binding – Everything is Allowed • UMTS Network consists of three domains: • Circuit Switched (CS) • Packet Switched (PS) • IP Multimedia Subsystem (IMS) • IMS is on top of PS domain • Pure IP / SIP are available via PS domain • Value added services are available via IMS • Registration is not necessary to set up SIP calls in UMTS • Calls to unregistered IMS users are possible (terminated at home service node, e.g. VoiceMail) • IMS users can be called from Non-IMS users and vice versa

  4. Privacy – To/From headers • Request Privacy by an extra header • Where is the caller identity transported? • Remote Party ID? • From header? • If From header is the solution then • P-CSCF needs to be able to change it • P-CSCF should not be mandated to act as B2BUA because of that, i.e. send the changed value also to the UE in responses.

  5. XML Bodies and P-headers • 3GPP specific information currently is transported in a XML body • IETF: XML should be opaque to Proxies • CSCF’s are transparent B2BUAs • 3GPP is basically willing to migrate to P-headers for most of the information • It may be more appropriate to transport 3G specific data which is purely not SIP related (e.g. 3GPP filtering related) within XML-bodies • Problems? • ID (intended as informational RFC) will be brought up in the near future, listing all the 3GPP specific information which should go into P-headers.

  6. P-Headers • Charging-Information • ICID (IMS Charging ID) and GPRS CID for correlation and identification purposes – ICID generated by first IMS network entity – globally unique • Charging Control Function (CCF) Address • Visited Network ID • Cell-ID • Originally dialed Public User ID (Target Address-of-Record) • 3GPP specific or general requirement? • Relation to Visited Header? • P-Header? • Possible to be solved with To-Header manipulation? (Backwards compatibility …)

  7. Security • AKA via HTTP-Digest • How AKA works • MD5 versus RES • Integrity Protection • HTTP-Digest extension • IPSec • Draft Arkko Sip-Sec agree • Key Transport (CK, IK) from S-CSCF to P-CSCF • (S)MIME? • P-Header? • XML Body? • Tag in existing header?

More Related