1 / 27

Open Issues in bis

Open Issues in bis. Jonathan Rosenberg dynamicsoft. Current SIP model One INVITE at a time Within an INVITE, other non-INVITEs Each non-INVITE cannot overlap This has limitations Non-INV throughput 1/RTT Cannot update INVITE (early media). Issue 113: Overlapping Forward Transactions.

ayvette
Download Presentation

Open Issues in bis

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. Open Issues in bis Jonathan Rosenberg dynamicsoft

  2. Current SIP model One INVITE at a time Within an INVITE, other non-INVITEs Each non-INVITE cannot overlap This has limitations Non-INV throughput 1/RTT Cannot update INVITE (early media) Issue 113: Overlapping Forward Transactions INVITE INFO PRACK INFO

  3. INVITE: Confusion about most recent session description Cannot determine ordering of SDP in both responses Non-INVITE Cannot guarantee sequence delivery Proposal? Allow overlapping INV Each request must have full state (Contact) Most recent response has precedence Allow overlapping non-INV Notion of “full state” nonsensical Strict sequencing within content Why did we do it?

  4. Spec allows CANCEL for non-INVITE Why is that silly? Non-INVITE must be answered immediately CANCEL usage therefore always a race condition Why does it make sense? May still be human interaction Timeouts – wish to give up when no response comes Proposal: remove Open Issue #7: CANCEL for non-INVITE

  5. If a client sends a request to URI with an maddr, using the maddr, should it strip it first? Bis-03 routing rules say yes However, routing rules also specify that processing when you receive your own maddr same as if it weren’t there, so it doesn’t matter if prior hop stripped it This was contentious at prior IETFs Bis-03 specified this, but no comments Is this OK?? Open Issue #10: Stripping maddr

  6. Can a proxy record-route non-INVITE mid-call requests? If so, what does it mean? Proposal: Proxies can record-route anything UA ignore the RR For non-INVITE “session” things (SUBSCRIBE) Proxies can record-route anything UA behavior is method dependent according to session thing I.e., SUBSCRIBE can say that NOTIFY RR establishes a route set if there was none Open Issue #11: Record-Routing non-INVITE mid-call

  7. If offer SDP contains unicast addresses, can answer contain multicast? What does it mean? Is this an invitation to use that multicast group instead? Treat multicast like unicast (A->B unicast, B->A multicast) What if caller doesn’t do multicast? Proposal General rule: answer should be something offerer can use So, don’t send multicast in answer If offer is multicast, don’t send unicast in answer Re-invite for existing unicast stream can be multicast -> invitation to switch media to multicast Open Issue #20: Mixing uni/multi in offer/answer

  8. SDP section defines processing separately for multicast and unicast BUT, does so at the level of entire SDP An SDP can have a mix of both Proposal: Restructure appendix to treat uni/multi on a stream by stream basis Open Issue #21: uni/multi SDP processing rules too granular

  9. Spec says you cannot reuse a dynamic PT number you used previously for a different codec type I.e, can’t use PT 10 for stream 1 PCMU, re-INVITE that stream to GSM w/ same PT Also can’t ever reuse it Limits number of codecs in a call to 127 In principal, can reuse it once you’ve transitioned to the new one, no chance of confusion. The restriction is there to not require SIP signaling to be dependent on media synchronization Should restriction be lifted? Proposal: no Open Issue #23: dynamic PT reuse

  10. Spec says that once you’ve disabled a stream (port zero) you can’t reuse it Result is that SDP size increases as you disable/add streams Why? MUST maintain implicit ordering of codecs Problem is increasing size of SDP Issue for 3gpp it seems Proposal Can never remove a disabled stream But, if you add a new one, it can take disabled streams’ “slot” within SDP Can be totally different media This keeps ordering without increasing size of SDP Open Issue #146: re-use disabled streams

  11. Bis-02 used to say that a UA SHOULD be prepared to handle misaligned SDP Gave some vague guidelines what to do, not clear what it means Bis-03 has removed this General rule: error handling is your own concern No comments received on this removal, this feature had been discussed on list Is this OK? Proposal: yes Open Issue #26: misaligned SDP

  12. Consider offer/answer model where SDP is in 2xx/ACK Consider a re-INVITE in this model Q: how does UAS reject entire SDP? In initial INVITE, we use a BYE Don’t want a BYE here! Possibilities: ACK, disabling all streams, then re-INVITE with old SDP What if response to that re-INVITE is non-2xx? Define a NACK Same as ACK, but cancels transaction NOT BACKWARDS COMPATIBLE! Others? Open Issue #58: rejected mid-call SDP in 2xx

  13. RTT estimation done by computing difference from Timestamp in request from response However, retransmits of a message don’t update the timestamp Very painful to do that Result is that RTT estimate will be wrong How is this handled in TCP? (known issue there, I think) Solutions here? Bigger question: what do you do with RTT estimates? Open Issue #71: RTT Estimation with Timestamp

  14. Spec says that servers send no response to a multicast CANCEL How does client know when to stop retransmitting? No way! Proposals: Never send CANCEL over multicast Never send SIP over multicast Just continue retransmitting until timeout Send CANCEL responses over multicast May need to limit scope Open Issue #72: Multicast CANCEL

  15. If a UA receives an INVITE with held SDP, does it respond with held SDP? Bis-03+ says NO This has been discussed on list extensively prior to bis-03 Few comments on resolution: want broader input Open Issue #73: Responding to held SDP with held SDP

  16. Spec says a UA should cache its credentials for a proxy, and reuse next time it sends to that proxy How does UA know what proxy its sending to? No easy way for initial requests For re-INVITES, depends if that proxy record-routed – no easy way to know! If proxy didn’t record-route, Proxy-Auth never stripped Proposals Don’t bother Increase re-invite latency But, one-time nonces may require this anyway Use all those you used in initial INVITE Big issue if not stripped? Open Issue #81: Caching of SIP Proxy Credentials

  17. Consider race condition on right CANCEL never takes effect Result is excessive timeouts for transaction, higher probability of multiple 200 OK Cannot resubmit CANCEL! Would be seen as retransmit Proposal: Don’t CANCEL unless you get provisional response Latency/buffering issues? Open Issue #84: CANCEL/Request Race INVITE CANCEL 481 UAC UAS

  18. Bis-04 says that if you get a 481 to INVITE, consider the call leg down Question: should you send BYE? Proposal: YES! Why? Don’t want to change fact that mid-call re-INVITE failures don’t terminate call One way to terminate calls Furthermore If media streams from A->B generate errors to A, or RTCP times out, re-INVITE to B If that generates 481, then BYE Why: reconstitute draft Open Issue #118: 481 then BYE?

  19. Would like to have BYE/CANCEL Reason phrases/codes Compatible with PSTN Differing UA behaviors depending on reason for CANCEL UA hangup vs. other branch completed (drop to voicemail!) 3pcc treatments Issue: what codes to use Proposal: existing response codes/reason phrases Mostly for 3pcc case But: need more! Like why CANCEL was sent in forking case Open Issue #121 BYE/CANCEL Reason Phrases

  20. When a forking proxy gets a 2xx/6xx on a branch, is CANCEL of other branches a: MAY MUST SHOULD Bis-03 and previous were MAY, -04 is SHOULD Why? Without cancellation, burden moves to UA UA doesn’t know if proxy forked! Would always need to send CANCEL after 2xx Why not? Useful apps for not cancelling Proposal MUST Caller prefs to turn off Open Issue #122: CANCEL on 200/600 strength

  21. To hang up a call before a final response, does the UAC BYE, no tags CANCEL, then BYE if 2xx CANCEL + BYE no tags Related: can CANCEL have tags to be “directed” Related: can you send BYE for a 1xx “early leg” Proposal: CANCEL for all, then BYE on 2xx You can terminate a particular early leg with BYE w/ tags CANCEL w/ tags worse since No bodies Not e2e Open Issue #130: BYE v. CANCEL

  22. Using 0.0.0.0 on-hold has some issues: No IP for receiving receiver reports IPv4 specific Makes no sense for connection oriented media IP change may require change in security context Be explicit, not implicit Proposal: Use a=sendonly for bidirectional media Use a=inactive for recvonly Must still be prepared to receive 0.0.0.0 for backwards compatibility, but don’t send anymore No other explicit hold indicator needed Open Issue #133: on-hold indication

  23. Spec has many ways to say “don’t send me media”: A=sendonly A=inactive Bw=0 Port zero 0.0.0.0 Do we need all of these?? Answer: no, but we need several: A=sendonly stops receipt of media A=inactive stops RTP/RTCP in both directions Port zero terminates media stream (stop tools) All others not needed OK? Related #150: Saying “don’t send”

  24. How to do source routing? Preloaded routes with strict interpretation Preloaded routes with loose interpretation How is it done? {sip:user@host1}@host2;user=url Sip:user@host1;maddr=host2 Axes for analysis: Robustness to crashed servers Interoperability Cleanness Comments? Open Issue #159: Source Routing

  25. Forking for INVITE Deprecate in favor of B2BUA? NO! Forking for non-INVITE Must have three-way handshake Can it be done in a method independent way? Proposal: Allow it Method specific resolution SUB/NOTIFY defines a way, for example Open Issue #138: To fork, or not to fork

  26. Problem: Call leg ID includes a combination of To/From/Call-ID, which includes URLs SIP URLs make lousy identifiers Must canonicalize Long Problem: From field in reverse re-INVITEs may not be the sender of the request! Loss of idempotency Proposal: Re-define call-leg ID with tags/Call-ID ONLY Needs Supported header in INVITE/2xx No impact on proxies though Benefits Re-INVITEs can carry real identity Faster call leg lookups Glare scenario improved Replaces header easier Open Issue #140: Call Leg w/o URLs

  27. SIP spec has an appendix with SDP usage Not really a SIP issue at all Other descriptions will come along Sync issue with SDP spec Beefiness of SIP spec already Some ideas Separate RFC Incorporate into SDP revision Keep it as it is Proposal: Keep it as it is Open Issue #163: SDP, Where art thou?

More Related