1 / 9

SIP header reduction for supporting delay sensitive applications

SIP header reduction for supporting delay sensitive applications. draft-akhtar-sipping-header-reduction-00.txt draft-akhtar-sipping-3g-static-dictionary-00.txt. Haseeb Akhtar: haseebak@nortel.com Dave Brombal: davidb@nortel.com Anthony Jones: ajones@nortel.com

nblue
Download Presentation

SIP header reduction for supporting delay sensitive applications

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. SIP header reduction for supporting delay sensitive applications draft-akhtar-sipping-header-reduction-00.txt draft-akhtar-sipping-3g-static-dictionary-00.txt Haseeb Akhtar: haseebak@nortel.com Dave Brombal: davidb@nortel.com Anthony Jones: ajones@nortel.com Mohamed Khalil: mkhalil@nortel.com

  2. SIP Header Reduction Requirements for Wireless Access • Short call setup time • PDD (Post Dial Delay) < 4 sec for VoIP/VT applications • Push-to-beep < 1 sec for PTT (Push to Talk) application • Wireless bandwidth is restrictive • Even for 3G/4G technologies the average throughput per user is in the 10s of Kbytes • Number of users/sector • Distance from the cell tower • Interference from neighboring sectors • Use control channel to send/receive initial SIP messages • Removes traffic channel acquisition delay from the call setup time • Large text-based SIP messages can not be transmitted Initial call setup messages (e.g. SIP Invite, 200 OK) must be reduced to ~200 bytes to support delay sensitive applications over wireless access

  3. Using SigComp Alone • Initial SIP Invite message does not have high compression ratio • Lack of saved states results in moderate compression • Register, Subscribe and Notify messages before Invite • Conservative estimate is at 50% compression ratio • Persistent states across calls may not be a viable option • Limited by memory storage and scalability of the proxy server • Only the active users are provisioned to store Sigcomp state at a given time • Initial SIP Invite continues to be a challenge for achieving higher compression • Subsequent SIP Invites after the user terminates the call start the SigComp with the state saved at SIP Registration • URI of the called party – 30 bytes • Calling party’s preferred identity (P-preferred Identity) – 30 bytes • URI of the calling party in ‘From’ header – 30 bytes • Calling party’s ‘Contact’ information – 30 bytes • Leaves 80 bytes to fit the rest of the Invite message In addition to SigComp, further optimization to initial SIP Invite is needed

  4. Main Components of SIP Header Reduction Proposal • Modification of SIP Registration • Establish context • Exchange indexed list of Identity components • IP addresses, URIs, contact list etc. • To be used in SIP header fields: ‘Via’, ‘From’, ‘Contact’, ‘P-Preferred-Identity’ etc. • Exchange indexed list of access networks supported • To be used in ‘P-Access-Network-Info’ SIP Header field • Exchange indexed list of security protocols supported • To be used in ‘Security-Verify’ SIP Header field • Identify supported functions • SIP Header Reduction algorithm • 3G dictionary • Requires new or modified SIP Header Fields • 3G Dictionary • Introduce new mobility data elements not present in RFC 3485 • Avoid dynamically building the dictionary since initial SIP Invite needs to be reduced • EA Function at the UA and Proxy Server • Encode/decode SIP header fields • Maintain SIP Header Reduction state information per SIP Registration session

  5. Example Call Flow – IMS/MMD based Session S-CSCF (scscf1) UE-A P-CSCF (pcscf1) Shared XDMS I-CSCF (icscf1_1) 1. Initial UE Registration request and Unauthorized Response HSS 4.Cx: User registration status query 7. Cx: S-CSCF registration notification 8*. Buddy list retrieval 10*. Buddy list retrieval 2. REGISTER 3. REGISTER • Establish context • Check supported options • Execute EA function 5. REGISTER 6. Authentication • Retrieve buddy list • Create indexed lists • Execute EA function 8/9. 200 OK 9/10. 200 OK 11. 200 OK * Both of these options will work

  6. New Option Tags and SIP Header Fields • Option Tags for ‘Supported’ Header Field • Option Tag ‘encode’ • Indicates if SIP Header Reduction is supported • Option Tag ‘3G-Dictionary’ • Indicates the presence/absence of 3G Dictionary • P-Encode-Identities • Index of public IDs (IP addresses, URIs, E.164 etc.) • P-Encode-Access-Networks • Index of supported access networks such as CDMA, 802.11 etc. • P-Encode-Security • Index of security protocols supported such as IPSec, TLS etc. • P-Contact-List • Index of contact List • P-Contact-List-Location • Location of the database (such as shared XDM) for storing the contact list

  7. New Data Elements of 3G Dictionary • SIP Header Field parameters • ‘Max-Forwards: 70’ • ‘P-Preferred-Identity’ • ‘P-Access-Network-Info’ • ‘Require: sec-agree, precondition’ • ‘Supported: 100 rel’ • ‘Spi:s’ • ‘Port:c=’ • ‘Port:s=’ • SDP parameters • ‘Content-Type: application/SDP’ • ‘a=des:qos mandatory, local sendrecv’ • ‘a=des:qos none, local sendrecv’ • ‘a=inactive’

  8. References [1] RFC 3320 [2] Applying SigComp to the Session Initiation Protocol (SIP) draft-ietf-rohc-sigcomp-sip-01.txt

  9. Thank You

More Related