draft-ietf-sipping-nat-scenarios-11.txt   draft-ietf-sipping-nat-scenarios-12.txt 
SIPPING Working Group C. Boulton SIPPING Working Group C. Boulton
Internet-Draft NS-Technologies Internet-Draft NS-Technologies
Intended status: BCP J. Rosenberg Intended status: BCP J. Rosenberg
Expires: December 4, 2010 Skype Expires: December 12, 2010 Skype
G. Camarillo G. Camarillo
Ericsson Ericsson
F. Audet F. Audet
Skype Skype
June 2, 2010 June 10, 2010
Best Current Practices for NAT Traversal for Client-Server SIP Best Current Practices for NAT Traversal for Client-Server SIP
draft-ietf-sipping-nat-scenarios-11 draft-ietf-sipping-nat-scenarios-12
Abstract Abstract
Traversal of the Session Initiation Protocol (SIP) and the sessions Traversal of the Session Initiation Protocol (SIP) and the sessions
it establishes through Network Address Translators (NATs) is a it establishes through Network Address Translators (NATs) is a
complex problem. Currently there are many deployment scenarios and complex problem. Currently there are many deployment scenarios and
traversal mechanisms for media traffic. This document aims to traversal mechanisms for media traffic. This document aims to
provide concrete recommendations and a unified method for NAT provide concrete recommendations and a unified method for NAT
traversal as well as documenting corresponding flows. traversal as well as documenting corresponding flows.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 4, 2010. This Internet-Draft will expire on December 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 9 skipping to change at page 4, line 9
2. Description of proposed solutions for both SIP protocol signaling 2. Description of proposed solutions for both SIP protocol signaling
and media signaling. and media signaling.
3. A set of basic and advanced flow scenarios. 3. A set of basic and advanced flow scenarios.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC4787]. document are to be interpreted as described in RFC 2119 [RFC2119].
It should be noted that the use of the term 'Endpoint Independent It should be noted that the use of the term 'Endpoint Independent
NAT' in this document refers to a NAT that is both 'Endpoint NAT' in this document refers to a NAT that is both 'Endpoint
Independent Filtering NAT' and 'Endpoint Independent Mapping NAT' per Independent Filtering NAT' and 'Endpoint Independent Mapping NAT' per
RFC 4787 [RFC4787] definition. RFC 4787 [RFC4787] definition.
3. Problem Statement 3. Problem Statement
The traversal of SIP through NATs can be split into two categories The traversal of SIP through NATs can be split into two categories
that both require attention - The core SIP signaling and associated that both require attention - The core SIP signaling and associated
skipping to change at page 16, line 8 skipping to change at page 16, line 8
In this example the client sends a SIP REGISTER request through a In this example the client sends a SIP REGISTER request through a
NAT. The client will include an 'rport' parameter as described in NAT. The client will include an 'rport' parameter as described in
Section 4.1.1 of this document for allowing traversal of UDP Section 4.1.1 of this document for allowing traversal of UDP
responses. The original request as illustrated in (1) in Figure 5 is responses. The original request as illustrated in (1) in Figure 5 is
a standard SIP REGISTER message: a standard SIP REGISTER message:
Message 1: Message 1:
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7 Via: SIP/2.0/UDP 192.0.2.2;rport;branch=z9hG4bKnashds7
Max-Forwards: 70 Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=7F94778B653B From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70 Call-ID: 16CB75F21C70
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: path, outbound Supported: path, outbound
Contact: <sip:bob@192.168.1.2 >;reg-id=1 Contact: <sip:bob@192.0.2.2 >;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0 Content-Length: 0
This SIP transaction now generates a SIP 200 OK response, as depicted This SIP transaction now generates a SIP 200 OK response, as depicted
in (2) from Figure 5: in (2) from Figure 5:
Message 2: Message 2:
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7; Via: SIP/2.0/UDP 192.0.2.2;rport=8050;branch=z9hG4bKnashds7;
received=172.16.3.4 received=192.0.2.4
From: Bob <sip:bob@example.com>;tag=7F94778B653B From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>;tag=6AF99445E44A To: Bob <sip:bob@example.com>;tag=6AF99445E44A
Call-ID: 16CB75F21C70 Call-ID: 16CB75F21C70
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: path, outbound Supported: path, outbound
Require: outbound Require: outbound
Contact: <sip:bob@192.168.1.2 >;reg-id=1;expires=3600 Contact: <sip:bob@192.0.2.2 >;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0 Content-Length: 0
The response will be sent to the address appearing in the 'received' The response will be sent to the address appearing in the 'received'
parameter of the SIP 'Via' header (address 172.16.3.4). The response parameter of the SIP 'Via' header (address 192.0.2.4). The response
will not be sent to the port deduced from the SIP 'Via' header, as will not be sent to the port deduced from the SIP 'Via' header, as
per standard SIP operation but will be sent to the value that has per standard SIP operation but will be sent to the value that has
been stamped in the 'rport' parameter of the SIP 'Via' header (port been stamped in the 'rport' parameter of the SIP 'Via' header (port
8050). For the response to successfully traverse the NAT, all of the 8050). For the response to successfully traverse the NAT, all of the
conventions defined in RFC 3581 [RFC3581] MUST be obeyed. Make note conventions defined in RFC 3581 [RFC3581] MUST be obeyed. Make note
of both the 'reg-id' and 'sip.instance' contact header parameters. of both the 'reg-id' and 'sip.instance' contact header parameters.
They are used to establish an Outbound connection tuple as defined in They are used to establish an Outbound connection tuple as defined in
[RFC5626]. The connection tuple creation is clearly shown in [RFC5626]. The connection tuple creation is clearly shown in
Figure 5. This ensures that any inbound request that causes a Figure 5. This ensures that any inbound request that causes a
registration lookup will result in the re-use of the connection path registration lookup will result in the re-use of the connection path
skipping to change at page 17, line 39 skipping to change at page 17, line 39
Traversal of SIP REGISTER requests/responses using a reliable, Traversal of SIP REGISTER requests/responses using a reliable,
connection orientated protocol such as TCP does not require any connection orientated protocol such as TCP does not require any
additional core SIP signaling extensions, beyond the procedures additional core SIP signaling extensions, beyond the procedures
defined in [RFC5626]. SIP responses will re-use the connection defined in [RFC5626]. SIP responses will re-use the connection
created for the initial REGISTER request, (1) from Figure 6: created for the initial REGISTER request, (1) from Figure 6:
Message 1: Message 1:
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
Max-Forwards: 70 Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=7F94778B653B From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70 Call-ID: 16CB75F21C70
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: path, outbound Supported: path, outbound
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1 Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0 Content-Length: 0
Message 2: Message 2:
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
From: Bob <sip:bob@example.com>;tag=7F94778B653B From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>;tag=6AF99445E44A To: Bob <sip:bob@example.com>;tag=6AF99445E44A
Call-ID: 16CB75F21C70 Call-ID: 16CB75F21C70
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: path, outbound Supported: path, outbound
Require: outbound Require: outbound
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1;expires=3600 Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0 Content-Length: 0
This example was included to show the inclusion of the +sip.instance This example was included to show the inclusion of the +sip.instance
Contact header parameter as defined in the SIP Outbound specification Contact header parameter as defined in the SIP Outbound specification
[RFC5626]. This creates an association tuple as described in the [RFC5626]. This creates an association tuple as described in the
previous example for future inbound requests directed at the newly previous example for future inbound requests directed at the newly
created registration binding with the only difference that the created registration binding with the only difference that the
association is with a TCP connection, not a UDP pin hole binding. association is with a TCP connection, not a UDP pin hole binding.
skipping to change at page 20, line 6 skipping to change at page 20, line 6
3327 [RFC3327]. The previously created flow association token is 3327 [RFC3327]. The previously created flow association token is
inserted in a position within the Path header where it can easily be inserted in a position within the Path header where it can easily be
retrieved at a later point when receiving messages to be routed to retrieved at a later point when receiving messages to be routed to
the registration binding (in this case the user part of the SIP URI). the registration binding (in this case the user part of the SIP URI).
The REGISTER message of (1) includes a SIP Route header for the edge The REGISTER message of (1) includes a SIP Route header for the edge
proxy. proxy.
Message 1: Message 1:
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
Max-Forwards: 70 Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=7F94778B653B From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70 Call-ID: 16CB75F21C70
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: path, outbound Supported: path, outbound
Route: <sip:ep1.example.com;lr> Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1 Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0 Content-Length: 0
When proxied in (2) looks as follows: When proxied in (2) looks as follows:
Message 2: Message 2:
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP ep1.example.com;branch=z9hG4bKnuiqisi Via: SIP/2.0/TCP ep1.example.com;branch=z9hG4bKnuiqisi
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
Max-Forwards: 69 Max-Forwards: 69
From: Bob <sip:bob@example.com>;tag=7F94778B653B From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70 Call-ID: 16CB75F21C70
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: path, outbound Supported: path, outbound
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1 Contact: <sip:bob@192.0.2.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob> Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Content-Length: 0 Content-Length: 0
This REGISTER request results in the Path header being stored along This REGISTER request results in the Path header being stored along
with the AOR and it's associated binding at the Registrar. The URI with the AOR and it's associated binding at the Registrar. The URI
contained in the Path header will be inserted as a pre-loaded SIP contained in the Path header will be inserted as a pre-loaded SIP
'Route' header into any request that arrives at the Registrar and is 'Route' header into any request that arrives at the Registrar and is
directed towards the associated AOR binding. This all but guarantees directed towards the associated AOR binding. This all but guarantees
that all requests for the new registration will be forwarded to the that all requests for the new registration will be forwarded to the
skipping to change at page 23, line 6 skipping to change at page 23, line 6
Figure 8: Initiating a Session - UDP Figure 8: Initiating a Session - UDP
The initiating client generates an INVITE request that is to be sent The initiating client generates an INVITE request that is to be sent
through the NAT to a Proxy server. The INVITE message is represented through the NAT to a Proxy server. The INVITE message is represented
in Figure 8 by (1) and is as follows: in Figure 8 by (1) and is as follows:
Message 1: Message 1:
INVITE sip:alice@a.example SIP/2.0 INVITE sip:alice@a.example SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7 Via: SIP/2.0/UDP 192.0.2.2;rport;branch=z9hG4bKnashds7
Max-Forwards: 70 Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=ldw22z From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example> To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3 Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE CSeq: 1 INVITE
Supported: outbound Supported: outbound
Route: <sip:ep1.example.com;lr> Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;ob> Contact: <sip:bob@192.0.2.2;ob>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ...
[SDP not shown] [SDP not shown]
There are a number of points to note with this message: There are a number of points to note with this message:
1. Firstly, as with the registration example in Section 5.1.1.1, 1. Firstly, as with the registration example in Section 5.1.1.1,
responses to this request will not automatically pass back responses to this request will not automatically pass back
through a NAT and so the SIP 'Via' header 'rport' is included as through a NAT and so the SIP 'Via' header 'rport' is included as
skipping to change at page 24, line 5 skipping to change at page 24, line 5
requests will be sent to the same flow. Alternatively, a GRUU requests will be sent to the same flow. Alternatively, a GRUU
might have been used. See 4.3/[RFC5626]. might have been used. See 4.3/[RFC5626].
In (2), the proxy inserts itself in the Via, adds the rport port In (2), the proxy inserts itself in the Via, adds the rport port
number in the previous Via header, adds the received parameter in the number in the previous Via header, adds the received parameter in the
previous Via, removes the Route header, and inserts a Record-Route previous Via, removes the Route header, and inserts a Record-Route
with a token. with a token.
Message 2: Message 2:
INVITE sip:alice@172.16.1.4 SIP/2.0 INVITE sip:alice@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4bKnuiqisi Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4bKnuiqisi
Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7; Via: SIP/2.0/UDP 192.0.2.2;rport=8050;branch=z9hG4bKnashds7;
received=172.16.3.4 received=192.0.2.14
Max-Forwards: 69 Max-Forwards: 69
From: Bob <sip:bob@example.com>;tag=ldw22z From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example> To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3 Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE CSeq: 1 INVITE
Supported: outbound Supported: outbound
Record-Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr> Record-Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;ob> Contact: <sip:bob@192.0.2.2;ob>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ...
[SDP not shown] [SDP not shown]
5.1.3.2. Connection-oriented Transport 5.1.3.2. Connection-oriented Transport
When using a reliable transport such as TCP the call flow and When using a reliable transport such as TCP the call flow and
procedures for traversing a NAT are almost identical to those procedures for traversing a NAT are almost identical to those
described in Section 5.1.3.1. The primary difference when using described in Section 5.1.3.1. The primary difference when using
skipping to change at page 25, line 31 skipping to change at page 25, line 31
| | | | | | | |
| | | | | | | |
Figure 9: Receiving an Invitation to a Session Figure 9: Receiving an Invitation to a Session
An INVITE request arrives at the Authoritative Proxy with a An INVITE request arrives at the Authoritative Proxy with a
destination pointing to the AOR of that inserted in Section 5.1.1.1. destination pointing to the AOR of that inserted in Section 5.1.1.1.
The message is illustrated by (1) in Figure 9 and looks as follows: The message is illustrated by (1) in Figure 9 and looks as follows:
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 70 Max-Forwards: 70
From: External Alice <sip:alice@example.com>;tag=02935 From: External Alice <sip:alice@example.com>;tag=02935
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4> Contact: <sip:alice@192.0.2.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: .. Content-Length: ..
[SDP not shown] [SDP not shown]
The INVITE request matches the registration binding previously The INVITE request matches the registration binding previously
installed at the Registrar and the INVITE request-URI is re-written installed at the Registrar and the INVITE request-URI is re-written
to the selected onward address. The proxy then examines the request to the selected onward address. The proxy then examines the request
URI of the INVITE and compares with its list of connection tuples. URI of the INVITE and compares with its list of connection tuples.
It uses the incoming AOR to commence the check for associated open It uses the incoming AOR to commence the check for associated open
connections/mappings. Once matched, the proxy checks to see if the connections/mappings. Once matched, the proxy checks to see if the
unique instance identifier (+sip.instance) associated with the unique instance identifier (+sip.instance) associated with the
binding equals the same instance identifier associated with that binding equals the same instance identifier associated with that
connection tuple. The request is then dispatched on the appropriate connection tuple. The request is then dispatched on the appropriate
binding. This is message (2) from Figure 9 and is as follows: binding. This is message (2) from Figure 9 and is as follows:
INVITE sip:bob@192.168.1.2 SIP/2.0 INVITE sip:bob@192.0.2.2 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4kmlds893jhsd Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4kmlds893jhsd
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 69 Max-Forwards: 69
From: Alice <sip:alice@example.com>;tag=02935 From: Alice <sip:alice@example.com>;tag=02935
To: client bob <sip:bob@example.com> To: client bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4> Contact: <sip:alice@192.0.2.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: .. Content-Length: ..
[SDP not shown] [SDP not shown]
It is a standard SIP INVITE request with no additional functionality. It is a standard SIP INVITE request with no additional functionality.
The major difference being that this request will not be forwarded to The major difference being that this request will not be forwarded to
the address specified in the Request-URI, as standard SIP rules would the address specified in the Request-URI, as standard SIP rules would
enforce but will be sent on the flow associated with the registration enforce but will be sent on the flow associated with the registration
binding (look-up procedures in RFC 3263 [RFC3263] are overridden). binding (look-up procedures in RFC 3263 [RFC3263] are overridden).
skipping to change at page 27, line 33 skipping to change at page 27, line 33
| | | | | | | | | |
| | | | | | | | | |
Figure 10: Registrar/Proxy Not Co-located Figure 10: Registrar/Proxy Not Co-located
An INVITE request arrives at the Authoritative Proxy with a An INVITE request arrives at the Authoritative Proxy with a
destination pointing to the AOR of that inserted in Section 5.1.2. destination pointing to the AOR of that inserted in Section 5.1.2.
The message is illustrated by (1) in Figure 10 and looks as follows: The message is illustrated by (1) in Figure 10 and looks as follows:
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=02935 From: Alice <sip:alice@example.com>;tag=02935
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:external@172.16.1.4> Contact: <sip:external@192.0.2.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: .. Content-Length: ..
[SDP not shown] [SDP not shown]
The INVITE request matches the registration binding previously The INVITE request matches the registration binding previously
installed at the Registrar and the INVITE request-URI is re-written installed at the Registrar and the INVITE request-URI is re-written
to the selected onward address. The Registrar also identifies that a to the selected onward address. The Registrar also identifies that a
SIP PATH header was associated with the registration and pushes it SIP PATH header was associated with the registration and pushes it
into the INVITE request in the form of a pre-loaded SIP Route header. into the INVITE request in the form of a pre-loaded SIP Route header.
It then forwards the request on to the proxy identified in the SIP It then forwards the request on to the proxy identified in the SIP
Route header as shown in (2) from Figure 10: Route header as shown in (2) from Figure 10:
INVITE sip:bob@client.example.com SIP/2.0 INVITE sip:bob@client.example.com SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bK74huHJ37d
Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob> Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Max-Forwards: 69 Max-Forwards: 69
From: Alice <sip:alice@example.net>;tag=02935 From: Alice <sip:alice@example.net>;tag=02935
To: Bob <sip:Bob@example.com> To: Bob <sip:Bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4> Contact: <sip:alice@192.0.2.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: .. Content-Length: ..
[SDP not shown] [SDP not shown]
The request then arrives at the outbound proxy for the client. The The request then arrives at the outbound proxy for the client. The
proxy examines the request URI of the INVITE in conjunction with the proxy examines the request URI of the INVITE in conjunction with the
flow token that it previously inserted into the user part of the PATH flow token that it previously inserted into the user part of the PATH
header SIP URI (which now appears in the user part of the Route header SIP URI (which now appears in the user part of the Route
header in the incoming INVITE). The proxy locates the appropriate header in the incoming INVITE). The proxy locates the appropriate
flow and sends the message to the client, as shown in (3) from flow and sends the message to the client, as shown in (3) from
Figure 10: Figure 10:
INVITE sip:bob@192.168.1.2 SIP/2.0 INVITE sip:bob@192.0.2.2 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4nsi30dncmnl Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4nsi30dncmnl
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bK74huHJ37d
Record-Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr> Record-Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr>
Max-Forwards: 68 Max-Forwards: 68
From: Alice <sip:Alice@example.net>;tag=02935 From: Alice <sip:Alice@example.net>;tag=02935
To: bob <sip:bob@example.com> To: bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4> Contact: <sip:alice@192.0.2.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: .. Content-Length: ..
[SDP not shown] [SDP not shown]
It is a standard SIP INVITE request with no additional functionality It is a standard SIP INVITE request with no additional functionality
at the originator. The major difference being that this request will at the originator. The major difference being that this request will
not follow the address specified in the Request-URI when it reaches not follow the address specified in the Request-URI when it reaches
the outbound proxy, as standard SIP rules would enforce but will be the outbound proxy, as standard SIP rules would enforce but will be
sent on the flow associated with the registration binding as sent on the flow associated with the registration binding as
skipping to change at page 64, line 15 skipping to change at page 64, line 15
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-sip-connect-reuse] [I-D.ietf-sip-connect-reuse]
Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-14 (work in progress), draft-ietf-sip-connect-reuse-14 (work in progress),
August 2009. August 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
 End of changes. 36 change blocks. 
37 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/