RFC3261 (Almost) : Robert Sparks

RFC3261 (Almost)
Robert Sparks
Status of the New SIP RFC
 Passed IETF Last Call
 In the RFC Editor queue
 Author’s 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
SIPiT 10
2
Others from the bundle
 RFC 3262 : Reliability of Provisional Responses in SIP
<draft-ietf-sip-100rel-06.txt>
 RFC 3263 : SIP: Locating SIP Servers
<draft-ietf-sip-srv-06.txt>
 RFC 3264 : An Offer/Answer Model with SDP
<draft-ietf-mmusic-sdp-offer-answer-02.txt>
 RFC 3265 : SIP-Specific Event Notification
<draft-ietf-sip-events-05.txt>
 RFC 3266 : Support for IPv6 in SDP
<draft-ietf-mmusic-sdp-ipv6-02.txt>
 IMPORTANT: These numbers are assigned, but the RFCs do not yet
exists. Do not refer to them until they appear in the RFC archive.
SIPiT 10
3
Most Significant Changes Since December
 Loose Routing
 S/MIME
 TLS (sips:) mandatory for proxy/redirect/registrar
 TCP mandatory for UA
SIPiT 10
4
Loose Routing – The Problem
 Needed a way to specify a set of proxies for a dialog’s 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 B INVITE C INVITE D

A B C D
Route C,D Route D
SIPiT 10
5
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-compatibility with strict

routing SIP elements
 Support for loose routing is indicated through an “;lr” parameter.
INVITE D INVITE D INVITE D

A B C D
Route B,C Route C
SIPiT 10
6
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
SIPiT 10
7
Loose Routing - Example
U1->P1->P2->P3->P4->U2 : All but P3 are loose routing elements.
The INVITE arriving at U2 contains
INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.com;lr>
Record-Route: <sip:p3.middle.com>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>
U2 sends a BYE
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
Route: <sip:p2.example.com;lr>
SIPiT 10
8
P4 receives
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
And sends
BYE sip:p3.middle.com SIP/2.0
Route: <sip:caller@u1.example.com>
SIPiT 10
9
P3 receives
BYE sip:p3.middle.com SIP/2.0
And sends
BYE sip:p2.example.com;lr
P2 sees a URI it provided in the RURI so it rewrites this to

BYE sip:caller@u1.example.com
And sends it to P1
SIPiT 10
10
P1 Receives
And sends
SIPiT 10
11
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
SIPiT 10
12
TLS and sips:
 Implementation of TLS is mandatory for proxies, redirect servers and
registrars
 The ;transport=tls 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.
SIPiT 10
13
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
SIPiT 10
14
Progressing to Draft Standard
 ID -> Proposed Standard -> Draft Standard -> 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.
SIPiT 10
15
Useful Resources
 IETF Main Website : http://www.ietf.org
 Draft Repository : http://www.ietf.org/internet-drafts
 SIP Main Website : http://www.ietf.org/html-charters/sipwg.html
 SIP Supplementary Website : http://www.softarmor.com/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/
SIPiT 10
16
Information Resource
Robert Sparks
+1 972 473 5467
sip:rsparks@dynamicsoft.com
email:rsparks@dynamicsoft.com

RFC3261 (Almost) : Robert Sparks

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RFC3261 (Almost) : Robert Sparks

Uploaded by

Copyright:

Available Formats

RFC3261 (Almost)

 In the RFC Editor queue

 Author’s 48 hours review imminent

 TLS (sips:) mandatory for proxy/redirect/registrar

 TCP mandatory for UA

INVITE B INVITE C INVITE D

 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-compatibility with strict

INVITE D INVITE D INVITE D

 If the RURI of a request matches a URI you have previously placed in a

 If A Route header field exists in a message you are about to send:

P2 sees a URI it provided in the RURI so it rewrites this to

 Certificate identified by end user address

 Public key can be transported in SIP

 Entire message can be protected by “tunneling” the message in an

 A sips: URI scheme (otherwise identical to the sip: scheme) indicates

 Prevents UDP fragmentation

 Provides congestion control for large messages

 Establishes a connection for the transport of large responses

 Must provide Interop Statement

 Draft Repository : http://www.ietf.org/internet-drafts

 SIP Main Website : http://www.ietf.org/html-charters/sipwg.html

 SIP Supplementary Website : http://www.softarmor.com/sipwg

 Analogous pages exist at www.ietf .org for SIPPING and SIMPLE

You might also like