Sip working group
This presentation is the property of its rightful owner.
Sponsored Links
1 / 19

SIP Working Group PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

SIP Working Group. Jonathan Rosenberg dynamicsoft. Priority changed from token to integer Support for quoted strings, range and inequality operations Proxies don’t need to know tag definitions Conflict resolution between caller prefs and headers (Allow, Accept).

Download Presentation

SIP Working Group

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Sip working group

SIP Working Group

Jonathan Rosenberg


Caller preferences changes

Priority changed from token to integer

Support for quoted strings, range and inequality operations

Proxies don’t need to know tag definitions

Conflict resolution between caller prefs and headers (Allow, Accept)

Proposed model for using RFC 2533

Removed media tag, add per-media tags (audio, video, message)

Implicit media types

Implicit language preferences

Removed features attribute, added voicemail, attendant

Negations apply to elements, not entire disjunction

Caller Preferences Changes

Caller preferences changes1

Discussion of the caller-prefs parameter determination problem

Require-Contact support

Proxy strength for implementing matching algorithm is SHOULD

Return of only=TRUE in subtle form – usage of URI implicit attributes only done in UA

Events, methods implicit preferences use Require-Contact

RFC 2533 tutorial [Graham Okd]

Header usage for proxy changed from amr to r

Caller Preferences Changes

Open issue 1 forced parameter

If a UA doesn’t say anything about a param, it still matches a rule with that param.

This is a problem when used with Require Contact

Only works if UA indicates what they do AND what they don’t do

For example: require a call to go to voicemail

Puts burden on UA

Bad for future parameters that we want to Require

Open Issue #1: Forced Parameter

(& (foo=A) (bar=B))


(& (foo=A) (bar=B) (baz=C))

Open issue 2 and within single feature tag

In some cases you want to specify that a UA has to support multiple values for the same feature tag

INVITE method and SUBSCRIBE method

English and Spanish

Current mechanism is to use multiple values of the Require-Contact header field:

Can be tedious for long ANDs

Putting & within the quoted string results in feature set multiplication

Proposal: keep as is

Open Issue #2: AND within single feature tag

Require-Contact: *;methods=“INVITE”


Open issue 3 weight q values based on amount of overlap

Consider UA A:

Consider UA B:

And the Accept-Contact:

Both A and B match the rule

In some use cases, would like to preferentially try UA A first, as it is a “better” match

Proposal: develop q-value algorithm which weights based on amount of overlap

Can be done in RFC 2533 framework

Open Issue #3: Weight q-values based on amount of overlap

(&(video=TRUE) (audio=TRUE)




Open issue 4 merge require accept contacts

Require and Accept Contact are similar

Require says if it doesn’t match, discard

Accept says if it doesn’t match, try it last

Require says if it does match, keep it

Accept says if it does match, set its q-value to X

Proposal: Merge back into a single Accept-Contact header field

Define should-match parameter which, if the contact predicate doesn’t match, causes it to drop (sets q=0 otherwise)

Dovetails with must-match parameter, which says that it has to match EXPLICITLY even

Open Issue #4: Merge Require, Accept-Contacts

Open issue 5 no one cares

This draft continues to receive little group input

It is one of the most often cited drafts by other specs



Adaptation work

Proposal: Rewrite intro to give it a bit more spark, explain better the power of this spec

Its truly providing “one number” service – thats valuable

Open Issue #5: No one cares

Open issue 6 priority semantics

Not sure that the implicit preferences for Priority processing are right

Paul K had pointed out some issues on the list


Work through use cases

Define new algorithm

Possibly discard implicit preferences for priority -> mostly a callee thing

Open Issue #6: Priority Semantics

Open issue 7 implicit compatibility preference

An INVITE may have a feature set in the Contact URI

This describes the UAC

Might like to try to route it to a “maximally compatible” UAS

Can do that by using the Contact URI feature set as an implicit Accept-Contact feature set

Proposal: leave it out

Open Issue #7: Implicit compatibility preference

Open issue 8 escaping

Sadly, RFC 2533 syntax for feature tags uses characters not permitted in token

Slash (/) and colon (:)

These characters are in usage (URI based registrations)


Use characters allowed in token, but not in ftag, to represent those characters

Bang (!) gets mapped to colon

Single quote (‘) gets mapped to slash

Open Issue #8: Escaping


Add a “must-match” attribute to a Require-Contact rule

If the contact predicate does not contain an explicit value for all feature tags in the rule, eliminate the contact

Manifests itself as “pre-processing” before the rfc2533 matching process


Path forward

Path Forward

  • One more revision with these issues resolved

  • Then we are ready

    • Re-issue wglc??

  • What do do about use cases? Should it find a home somewhere?

Session timer

Session Timer

  • Status

    • -10 draft submitted

  • Changes

    • Rewrote overview of operation

    • 422 response causes you to retry with same Call-ID and bumped Cseq, like 401

    • Clarified that mid-dialog re-INVITE w/o session timer cancels session timer

Open issue

Open Issue

  • This draft seems to have problems

    • Many complaints that it is too complex

    • Seems to be limited interest

  • What might be the issue?

    • No defined requirements, not entirely clear the problem that is being solved

    • Proposition: only useful application is cleanup of state in proxies

    • Is it too complex for that usage?

What are the options

What are the options

  • Redefine the scope, removing some of the underlying requirements, develop a simpler solution

  • Keep the scope, but just clarify the wording

    • It can be better

  • Keep the scope, but pursue a completely new design

    • For example – just use the dialog package!

What method to use

What method to use?

  • What method to use for the refresh?

    • Historically, was just INVITE – for “stateless” operation

    • A few revs ago, we allowed UPDATE, w or w/o SDP

  • Proposal to use PING to align with RTSP

    • Still need session timer headers – not clear of benefit over UPDATE technically

Path forward1

Path Forward

  • Consensus appears to be option 2 – keep the scope and clean up the wording, to finish this off

  • Only issue is the method

    • Propose to keep UPDATE

Sips uri


  • Basic problem:

    • Text is a bit confused on whether its e2e or hop-by-hop

  • Additional problems

    • Mixed cases – SIPS URI in Contact 200 OK if it was nowhere else?

  • Solution

    • Need to come to agreement on the high level behavior

    • From there the detailed behaviors will flow

  • Login