Sip questions l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 33

SIP questions PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

SIP questions. Henning Schulzrinne Columbia University IRT Lab Siemens Munich -- January 2003. SIP bugs. 54 bugs listed likely lead to either an addendum or re-issue at Proposed

Download Presentation

SIP questions

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 questions l.jpg

SIP questions

Henning Schulzrinne

Columbia University IRT Lab


Munich -- January 2003

Sip bugs l.jpg

SIP bugs


  • 54 bugs listed

  • likely lead to either an addendum or re-issue at Proposed

    • Draft Standard requires promotion of DNS SRV, NAPTR, TLS, …  unlikely anytime soon

  • currently, in bug-gathering phase, since none are critical

    • a few require discussion

    • very few seem to have backwards-compatibility issues

Sip bugs editorial l.jpg

SIP bugs - editorial

Sip bugs editorial4 l.jpg

SIP bugs – editorial

Sip bugs security l.jpg

SIP bugs - security

Sip bugs error behavior l.jpg

SIP bugs – error behavior

Sip bugs error behavior7 l.jpg

SIP bugs – error behavior

Sip bugs protocol format issues l.jpg

SIP bugs – protocol format issues

Sip bugs uri transport l.jpg

SIP bugs – URI & transport

Sip bugs tags and branches l.jpg

SIP bugs – tags and branches

Sip bugs record route l.jpg

SIP bugs – Record-Route

Sip bugs dynamic behavior l.jpg

SIP bugs – dynamic behavior

Sip bugs early dialogs and media l.jpg

SIP bugs – early dialogs and media

Sip bugs events l.jpg

SIP bugs – events

Session model for instant messaging l.jpg

Session model for instant messaging

  • No recent public discussion, but apparently design team at work

    • moving towards SDP specific to CPIM messages, instead of comedia

  • Primary motivation:

    • bypass SIP proxies

    • reliable channel  avoid concerns about message size

    • more efficient encryption and signing

    • integration into multimedia sessions

  • Open issues:

    • proxies ever needed or is B2BUA good enough here?

  • Proposals:

    • SIP-lite 

    • BEEP 

    • CPIM (draft-campbell-simple-im-sessions, draft-campbell-simple-cpimmsg-sessions)

Cpim session model l.jpg

CPIM session model

  • draft-ietf-impp-cpim-msgfmt-07

  • Some annoying formatting differences to SIP, but close

  • SDP negotiation uses comedia, but doesn't fit well (port reuse, security)  in transition

c=IN IP4

m=message 7394 cpim/tcp text/plain


a=uri:im:[email protected]

c=IN IP4

m=message 8493 cpim/tcp text/plain text/html


a=uri:im:[email protected]

Cpim example l.jpg

CPIM example

From: MR SANDERS <im:[email protected]>

To: Depressed Donkey <im:[email protected]>

DateTime: 2000-12-13T13:40:00-08:00

Subject: the weather will be fine today

Subject:;lang=fr beau temps prevu pour aujourd'hui

NS: MyFeatures <mid:[email protected]>

Require: MyFeatures.VitalMessageOption

MyFeatures.VitalMessageOption: Confirmation-requested

MyFeatures.WackyMessageOption: Use-silly-font


encapsulated MIME content

Content-type: text/xml; charset=utf-8

Content-ID: <[email protected]>


Here is the text of my message.


Security l.jpg


  • Not much movement – considered first-stage complete

  • Work on Authenticated Identity Body (AIB)

    • signed subset of SIP

    • not clear how proxies can do the signing

  • Some murmurings on reviving Basic authentication

    • avoids storage of valuable key on server

  • What about untrusted end systems?

  • Proposal for public key retrieval via OPTIONS

  • Single sign-on: SAML and SIP?

Transport protocols l.jpg

Transport protocols

  • Clear movement towards TCP (and TLS)

  • No indications that SCTP is widely implemented in SIP proxies

    • not much performance benefit in practice (see Camarillo/Schulzrinne paper on performance comparison)

  • UDP not likely to disappear from spec (gratuitous incompatibility)

Stray responses l.jpg

Stray responses

  • Responses without proxy state are routed statelessly to UAC

  • Problem: 408 (timeout) for unreachable UAS can trigger an avalanche of responses

  • Proposal: suppress error responses or at least 408

  • Evaluation: 4xx needed by caller

    • avoid special cases

    • usually, only last proxy needs short (user-oriented) timeout  let it clean up the chain

    • however, not clear if proxy knows its position in chain

What is casp l.jpg

What is CASP?

  • Genericsignalingservice

    • establishes state along path of data

    • one sender, typically one receiver

      • can be multiple receivers  multicast

    • can be used for QoS per-flow or per-class reservation

    • anything that establishes temporary state roughly along a data path

    • but not restricted to QoS:

      • node and link discovery (link speed and properties, packet loss)

      • deposit active network code

      • control firewalls and NATs

  • avoid restricting users of protocol (and religious arguments):

    • sender vs. receiver orientation

    • more or less closely tied to data path

      • router-by-router (on-path)

      • network (AS) path (off-path)

Casp properties l.jpg

Network friendly


re-use of state across applications

mobility friendly

handles path changes

transport neutral

any reliable protocol

initially, TCP and SCTP

policy neutral

no particular AAA policy or protocol

interaction with COPS, DIAMETER needs work

soft state

per-node time-out

explicit removal


data format


Topology hiding

not recommended, but possible

Light weight

implementation complexity

security associations (re-use)

may not need kernel implementation

CASP properties

Casp network model on path l.jpg

CASP network model – on-path

selective ("vegetarian")

  • CASP nodes form CASP chain

  • not every node processes all client protocols:

    • non-CASP node: regular router

    • omnivorous: processes all CASP messages

    • selective: bypassed by CASP messages with unknown client protocols

CASP chain






Casp network model out of path l.jpg

CASP network model – out-of-path

Bandwidth broker



  • Also route network-by-network

  • can combine router-by-router with out-of-path messaging

  • Not well defined if several in one AS

  • basically, an inter-domain service location problem

  • IETF tool kit for distributed solutions:

    • SLP (with extension in progress)

    • DNS SRV/NAPTR (see SIP)

  • Probably not: multicast, anycast, LDAP



AS 1249


Casp protocol structure l.jpg

client layer does the real work:

reserve resources

open firewall ports

messaging layer:

establishes and tears down state

negotiates features and capabilities

transport layer:

reliable transport

CASP protocol structure

client layer


scout protocol

messaging layer


messaging layer


transport layer



IP router alert

Casp messages l.jpg

CASP messages

  • Regular CASP messages

    • establish or tear down state

    • carry client protocol

  • Scout messages

    • discover next hop

  • Hop-by-hop reliability

  • Generated by any node along the chain

Message forwarding l.jpg

Message forwarding

  • Route stateless or state-full:

    • stateless: record route and retrace

    • state-full: based on next-hop information in CASP node

  • Destination:

    • address  look at destination address

    • address + record  record route

    • route  based on recorded route

    • state forward  based on next-hop state

    • state backward  based on previous-hop state

  • State:

    • no-op  leave state as is

    • ADD  add message (and maybe client) state

    • DEL  delete message state

Next node discovery path coupled l.jpg

Next-node discovery: path-coupled

  • Discovery behavior options:

    • straight-through

    • hop-by-hop







  • routing protocol with probing

  • service discovery, e.g., SLP

  • first hop, e.g., router advertisements

  • DHCP

  • scout protocol

Next node discovery path coupled29 l.jpg

Next-node discovery: path-coupled

hop-by-hop discovery (“incremental”)







Combining flow through and transport sessions l.jpg

Combining flow-through and transport sessions







use existing transport connection if available

Mobility and route changes l.jpg

Mobility and route changes

  • avoids session identification by end point addresses

  • avoid use of traffic selector as session identifier

  • remove dead branch

DEL (B=2)

discovers new route

on refresh




Sip resilience l.jpg

SIP resilience

  • Similar to DNS  provide multiple servers, on different networks

    • failover via DNS SRV/NAPTR

    • with state replication

      • database replication may be too heavy-weight

      • copy REGISTER to all backup proxies

        • issue: digest authentication  third-party authentication

      • copy service logic, configuration to other servers

  • minimize call state bound to one server

    • specify server cluster as Route, not one server

  • SCTP between servers for failover

Casp ims l.jpg


  • Suitable for

    • RAN resource reservation

    • air interface control?

    • edge resource reservation

    • MIDCOM-style services

  • Login