1 / 9

SIP Working Group Stuff

SIP Working Group Stuff. Jonathan Rosenberg dynamicsoft. Rewrite for dependence on rfc2533 RFC2533 = A Syntax for Media Feature Sets Specifies matching of preferences and capabilities Initial application was HTTP Content Negotiation. Syntax is unchanged Spec describes how to map to rfc2533

dswitzer
Télécharger la présentation

SIP Working Group Stuff

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 Working Group Stuff Jonathan Rosenberg dynamicsoft

  2. Rewrite for dependence on rfc2533 RFC2533 = A Syntax for Media Feature Sets Specifies matching of preferences and capabilities Initial application was HTTP Content Negotiation Syntax is unchanged Spec describes how to map to rfc2533 Then points to 2533 for performing matching operation Optimizations are possible! 2533 algorithm is complex Caller prefs limits the types of expressions (conjunctive form on orthogonal tags) More efficient algorithms (like the one in –04) can be used Caller Preferences Changes

  3. “type” feature tag now only for complete types “media” tag for top level types – audio, video, message For alignment with existing tags Added automata tag Boolean For robots, voicemail servers Added “events” tag For RFC 3265 event types Presence, winfo, etc. Some changes in priority matching Can register multiple priorities:;priority=“urgent,emergency” However, multiple is redundant – lowest will be used Can also ask for explicit priorities in Accept-Contact Actual Semantic Changes

  4. Q-value has to be the last parameter amongst the Accept/Reject-Contact header values There is ONE construction for feature sets in all headers New: Explicit preferences Previously, server handled methods, priority differently Constructed caller preference from request method, Priority header Now, caller can explicitly state preference:A-Con: *;methods=“INVITE,REFER” Allows you to ask for a UA with specific capabilities Implicit still done, but explicit overrides implicit More Changes

  5. URI matching still allowed, but restricted User and host Just host All URI params ignored Unification of allowed feature sets between Contact and Accept-Contact Eliminate the & construct Based on RFC 2533 definition of feature sets, it doesn’t make sense as defined More Changes

  6. Overlap in Function when used in INVITE Contact Intent was to allow UA to describe itself Several parameters overlap with SIP headers Methods and Allow Events and Allow-Events Types,media and Accept Languages and Accept-Language What do we do about it? 1. Allow both, define one as taking priority 2. Forbid caller prefs from using params also present through headers 3. Disallow use of caller prefs in INVITE/200 Proposal: [1], with headers taking priority Open Issue #1: Overlap

  7. Caller prefs has no way to indicate which Contact params are “its” as opposed to another extension. Example:Contact: sip:u@d;extension-param=3;mobility=fixed Is “extension-param” for caller prefs or not? May not matter! It is present in both Accept-Contact and Contact, then it is Related Issue: Can we apply caller prefs to unknown parmeters? Would like to But what are the matching rules? Not clear from rfc 2533 if its allowed Open Issue #2: Other extensions

  8. Previous draft covered two problems Receiving responses through NAT (rport) Receiving requests through NAT (Translate header in REGISTER) Translate header had issues For UDP, required very frequent re-registers Introduced some NAT-specific things (nat-type parameter) Was a big hack Repeated what STUN was doing SIP-NAT

  9. Proposed new scope: Make sure SIP can work with STUN, SPAN, TURN No more, no less Result of the scope: only rport parameter remains Without this, STUN wouldn’t work Ultimately, TCP is the right answer In that case, only problem is registrations Handle that as a connection reuse problem Applies to proxy-proxy connections as well New Scope

More Related