RFC3261 (Almost)

1
RFC3261 (Almost)
Robert Sparks
2
Status of the New SIP RFC

• Passed IETF Last Call
• In the RFC Editor queue
• Authors 48 hours review imminent
• IMPORTANT RFC3261 does not officially exist yet,
  only the number has been assigned do not refer
  to it in papers/documentation until it appears in
  the RFC archive.
• Until then, refer to draft-ietf-sip-rfc2543bis-09.
  txt

3
Others from the bundle

• RFC 3262 Reliability of Provisional Responses
  in SIP ltdraft-ietf-sip-100rel-06
  .txtgt
• RFC 3263 SIP Locating SIP Servers
  ltdraft-ietf-sip-srv-06.txtgt
• RFC 3264 An Offer/Answer Model with SDP
  ltdraft-ietf-mmusic-sdp-offer-answer-02.
  txtgt
• RFC 3265 SIP-Specific Event Notification
  ltdraft-ietf-sip-events-05.txtgt
• RFC 3266 Support for IPv6 in SDP
  ltdraft-ietf-mmusic-sdp-ipv6-02.txtgt
• IMPORTANT These numbers are assigned, but the
  RFCs do not yet exists. Do not refer to them
  until they appear in the RFC archive.

4
Most Significant Changes Since December

• Loose Routing
• S/MIME
• TLS (sips) mandatory for proxy/redirect/registrar
  
• TCP mandatory for UA

5
Loose Routing The Problem

• Needed a way to specify a set of proxies for a
  dialogs initial request to traverse.
• Strict routing (Route/Record-Route as defined
  in bis-05 and before) was too strict. Service
  logic could not affect routing of the initial
  request.
• Strict routing conflates the request target with
  the next hop destination.
• Strict route processing throws away the
  information in the received Request-URI.
• Behavior of UAs with default-outbound-proxies
  problematic.
• Brittle system failure if any element misroutes.

INVITE BRoute C,D
INVITE CRoute D
INVITE D
C
A
B
D
6
Loose Routing The Solution

• Define Routing the right way clean slate
  design
• Keep request target and next route destination
  separate
• Allow each route destination to determine when it
  has been reached
• Then add mechanism to provide backwards-compatibil
  ity with strict routing SIP elements
• Support for loose routing is indicated through an
  lr parameter.

INVITE DRoute B,C
INVITE DRoute C
INVITE D
A
C
B
D
7
Loose Routing Processing Instructions

• If you are a strict router, follow old (bis-05)
  Route/Record-Route rules
• If the RURI of a request matches a URI you have
  previously placed in a Record-Route header field,
  the previous element is a strict router. Rewrite
  the message to repair what it did before further
  processing
• Move the last Route hvf into the RURI.
• If A Route header field exists in a message you
  are about to send
• If the top Route header field value (hfv) matches
  you, remove it.
• If the new top Route header field value indicates
  loose route support, forward the request to it.
• Otherwise, specially prepare the message to
  survive a strict router
• Place RURI in the Route header as the last hfv.
• Place the first hfv into the RURI.
• Forward the request based on the RURI

8
Loose Routing - Example

• U1-gtP1-gtP2-gtP3-gtP4-gtU2 All but P3 are loose
  routing elements.
• The INVITE arriving at U2 contains
• INVITE sipcallee_at_u2.domain.com SIP/2.0
• Contact sipcaller_at_u1.example.com
• Record-Route ltsipp4.domain.comlrgt
• Record-Route ltsipp3.middle.comgt
• Record-Route ltsipp2.example.comlrgt
• Record-Route ltsipp1.example.comlrgt
• U2 sends a BYE
• BYE sipcaller_at_u1.example.com SIP/2.0
• Route ltsipp4.domain.comlrgt
• Route ltsipp3.middle.comgt
• Route ltsipp2.example.comlrgt
• Route ltsipp1.example.comlrgt

9
Loose Routing - Example

• U1-gtP1-gtP2-gtP3-gtP4-gtU2 All but P3 are loose
  routing elements.
• P4 receives
• BYE sipcaller_at_u1.example.com SIP/2.0
• Route ltsipp4.domain.comlrgt
• Route ltsipp3.middle.comgt
• Route ltsipp2.example.comlrgt
• Route ltsipp1.example.comlrgt
• And sends
• BYE sipp3.middle.com SIP/2.0
• Route ltsipp2.example.comlrgt
• Route ltsipp1.example.comlrgt
• Route ltsipcaller_at_u1.example.comgt

10
Loose Routing - Example

• U1-gtP1-gtP2-gtP3-gtP4-gtU2 All but P3 are loose
  routing elements.
• P3 receives
• BYE sipp3.middle.com SIP/2.0
• Route ltsipp2.example.comlrgt
• Route ltsipp1.example.comlrgt
• Route ltsipcaller_at_u1.example.comgt
• And sends
• BYE sipp2.example.comlr
• Route ltsipp1.example.comlrgt
• Route ltsipcaller_at_u1.example.comgt
• P2 sees a URI it provided in the RURI so it
  rewrites this to
• BYE sipcaller_at_u1.example.com
• Route ltsipp1.example.comlrgt
• And sends it to P1

11
Loose Routing - Example

• U1-gtP1-gtP2-gtP3-gtP4-gtU2 All but P3 are loose
  routing elements.
• P1 Receives
• BYE sipcaller_at_u1.example.com
• Route ltsipp1.example.comlrgt
• And sends
• BYE sipcaller_at_u1.example.com

12
S/MIME

• Provides end-to-end security of message body
  and/or headers.
• Certificate identified by end user address
• Public key can be transported in SIP
• Entire message can be protected by tunneling
  the message in an S/MIME body

Header Fields
Header Fields
Body
Signature
13
TLS and sips

• Implementation of TLS is mandatory for proxies,
  redirect servers and registrars
• The transporttls URI parameter value is
  deprecated
• A sips URI scheme (otherwise identical to the
  sip scheme) indicates that all hops between the
  requestor and the resource identified by the URI
  must be encrypted with TLS.
• If the request is retargeted once the resource is
  reached, it must use secured transports.

14
TCP Mandatory for UA

• If a request is within 200 bytes of the path MTU,
  or if it is larger than 1300 bytes and the path
  MTU is unknown, the request MUST be sent using
  TCP.

• Prevents UDP fragmentation
• Provides congestion control for large messages
• Establishes a connection for the transport of
  large responses

15
Progressing to Draft Standard

• ID -gt Proposed Standard -gt Draft Standard -gt STD
• Must provide Interop Statement
• For each feature in the specification, two
  independent interoperable implementations must
  exist
• Any features not meeting that requirement must be
  removed from the specification
• SIPiT is a natural place to gather interop
  statements.

16
Useful Resources

• IETF Main Website http//www.ietf.org
• Draft Repository http//www.ietf.org/internet-dr
  afts
• SIP Main Website http//www.ietf.org/html-charte
  rs/sipwg.html
• SIP Supplementary Website http//www.softarmor.c
  om/sipwg
• Analogous pages exist at www.ietf .org for
  SIPPING and SIMPLE
• Mailing lists
• See the main IETF website for instructions on
  joining the SIP, SIPPING, or SIMPLE mailing lists
• See http//cs.columbia.edu/hgs/sip/

17
Information Resource

• Robert Sparks
• 1 972 473 5467
• siprsparks_at_dynamicsoft.com
• emailrsparks_at_dynamicsoft.com