1 / 7

3pcc Update and Issues

This document discusses call flow issues related to retransmissions and timeouts in SIP sessions. It proposes a solution that eliminates these problems and combines the best aspects of existing call flows. The document also highlights remaining issues and recommends further considerations for QoS preconditions and early media.

vlarry
Download Presentation

3pcc Update and Issues

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. 3pcc Update and Issues Jonathan Rosenberg dynamicsoft

  2. Initial Call Flow from -00 A Controller B | INV no SDP | | |<------------------| | | | | | 200 SDP A | | |-----------------> | INV SDP A | | |----------------->| | | | | | 200 SDP B | | |<-----------------| | | | | | ACK | | ACK SDP B |----------------->| |<------------------| | | | | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | • Big problem: • Retransmissions of 200 from A to controller while we wait for B

  3. Call flow from -01 A Controller B | INV held SDP | | |<------------------| | | | | | 200 SDP A | | |-----------------> | INV SDP A | | ACK |----------------->| |<----------------- | | | | 200 SDP B | | |<-----------------| | | | | | ACK | | INV SDP B |----------------->| |<------------------| | | 200 OK SDP A | | |------------------>| | | ACK | | |<------------------| | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | • Fixes timeout problem completely • Each transaction independent • Big problems though • Relies on A returning same SDP in re-INVITE • Otherwise, infinite re-INVITE loops! • Also assumes controller knows media

  4. A Controller B | INV no SDP | | time t = 0 |<------------------| | | | | | 200 SDP A1 | | |-----------------> | | | | | | ACK SDP held | | |<------------------| | | | | | | INV no SDP | | |----------------->| | | | | | 200 SDP B | | |<-----------------| | INV SDP B' | | |<------------------| | | | | | 200 SDP A2 | | |-----------------> | | | | | | | ACK SDP A2' | | ACK |----------------->| |<------------------| | | | | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | Latest call flow • Combines best of all call flows • No timeouts, since reinvite will generally be answered fast • No infinite recursion • No media assumption • But • Complex • Still requires SDP manipulation for multiple streams and differing codec bindings

  5. Requires that INVITE on hold not generate hold as response Proposal is to document this in RFC Whole reason we chose 0.0.0.0 is that normal SDP processing would give hold Only special case processing would generate hold in response! Requires that re-INVITE w/ no SDP mean “you tell me what SDP to use” Response is probably same SDP as before, need not be Agreed to this at bof Will document in bis SIP Issues

  6. Call flow 1 still useful in some cases! When you know that 2nd party is automata that answers right away Many examples Conference servers Media servers Messaging servers Still simplest and best if timeout not problem Call flow 3 most general, and recommended when you don’t know if 1 will work Recommendations

  7. QoS preconditions makes my head hurt A lot more thinking needed here Allowing ringing to one user No way for either user to hear ringback when they pick up One solution is to reverse direction of one call leg REFER back to yourself! Anything else? Early media? Most important thing are SIP changes/clarifications needed for this service Issues that remain

More Related