1 / 20

SIPPING IETF 57

SIPPING IETF 57. Jonathan Rosenberg dynamicsoft. Status. IETF 56 First introduced Proposal was: Adopt as WG item Replace sipping-nat-scenarios with ICE-based flows Preconditions work in sip Good interest, hum to make it working item, but seemed like few had really read it yet

ayita
Download Presentation

SIPPING IETF 57

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 IETF 57 Jonathan Rosenberg dynamicsoft

  2. Status • IETF 56 • First introduced • Proposal was: • Adopt as WG item • Replace sipping-nat-scenarios with ICE-based flows • Preconditions work in sip • Good interest, hum to make it working item, but seemed like few had really read it yet • Concerns expressed during meeting • Backwards compatibility • Replace nat-scenarios: need to see it • Too complex

  3. Ice-01 • Addressed concerns expressed in IETF 56 • Backwards compatibility • No longer using ALT semantic of SDP grouping extension • Instead, using an “alt” attribute • M and c lines contain address most likely to succeed • Result is that when ICE-aware client calls non-ICE-aware, there is no extra RTT, no Require header needed

  4. Scenarios • Ice-01 has nearly 50 pages of example flows • These are the content of the proposed replacement of sipping-nat-scenarios • Outcome • Shows how the same client behavior and overall algorithm work for • Residential • Enterprise • Centrex • Some more flows needed, some more work needed

  5. Other ICE changes • Answer construction simplified – including all your addresses. • Used to need to fragment to deal with m-line matching requirements • Optimization to avoid extra cycles: don’t offer a new address if peer has already connected to a higher priority one • Connected determined by receipt of STUN • Removed suggested q-values – only ordering important • Partial alignment to parallel TURN rev

  6. Technical Open Issues • Determining “address most likely to work” for population into m and c lines – need an algorithm • Won’t always be right – enterprise • Do we need to deal with enterprise firewall policies which prevent outbound UDP from any internal host? • May need to add outbound relay – ala MSRP – to TURN

  7. Process Open Issues • Do we want to proceed with this, and if so, where? • ICE helps with many problems • NAT traversal • IPv4/IPv6 transition – used in v6ops transition documents • RTSP – may be used by them too • RTP DoS Prevention: see draft-rosenberg-mmusic-rtp-denialofservice • Proposal: Proceed

  8. How to proceed • ICE needs to be split into four documents: • Main ICE Behavior: BCP in sipping or mmusic • SDP Extensions: mmusic • Precondition: do people care? If so, sip wg (will need requirements) • Usage Scenarios with SIP: sipping – replacing sipping-nat-scenarios • Volunteers to help with some of this?

  9. Session Policy

  10. Changes from previous version • Name change to reflect wg item • Minor typos and cleanup • No real substantial changes – has had limited email discussion, though folks have continued to express interest

  11. Open Issues • Issue 1: Dynamic vs. Static Policies • The requirements are written in a way that assumes that policies are made during call setup (dynamic) • Some policies can be done outside of a call (static): • What codecs to use • Some policies are inherently dynamic • Intermediary to use – port is specified per call • Static is much simpler • Do we need dynamic?? • May be other approaches – ICE ?? • May not work for CALEA – depends on your interpretation

  12. Open Issues • Do UAC and UAS need to know about media changes requested of their peer? • Do we need to encrypt media policies so that only UAC/UAS can see them? • Hard to achieve • Sips would get us privacy excepting in-path elements – seems good enough to me • Mechanism must not introduce DoS – is this stating the obvious? • Proposal: rephrase as – must not introduce amplification on unauthenticated requests

  13. URI Leasing

  14. History • General problem: How to route a request outside of a dialog to a specific UA instance • Conferencing – ad-hoc conferences • Assisted Transfer • Presence • Draft-rosenberg-sipping-lease written with requirements and proposed solution • Assumes that the right answer is to “lease” an AOR for the UA instace

  15. IETF 56 • Others feel that using embedded Route headers is a better solution • Confusion about level of complexity implied by lease solution • Confusion about what the requirements document should look like

  16. Progress • An informal group met @IETF57 • Rosenberg, Jennings, Kyzivat, Johnston, Mahy • Our conclusions • Leasing approach is the right way to go • The sipping requirements document should focus on the small number of requirements for solving the GRUU problem • I.e., they are not leasing requirements

  17. Why leasing? • Embedded route headers imply that the proxy doesn’t know that this is a request to an AOR (a GRUU is an AOR) • Proxies can’t apply policy • Proxies can’t apply user services • Can be done statelessly • Side effect of register request • Can provide privacy

  18. Client sends REGISTER request Response contains a GRUU Prefix in a header Client can append user-data to GRUU Prefix to build an AOR Proxy forwards requests for that AOR to the contact it is bound to User-data also passed to user Current Mechanism Thinking INV sip:aahu.userpart@example.com Registrar 200 OK GRUU: aahu REG M:sip:c1@1.2.3.4 Client INV sip:c1@1.2.3.4;gruu-info=userpart

  19. Open Issues • Do we need to generally allow a UA to obtain an unlimited number of GRUU? • Needed for conferencing, but other applications? • Does the GRUU go into the Contact header of INV/200? • Will be the end of direct signaling… • Syntax of the URIs

More Related