RFC 6314
NAT Traversal Practices for Client-Server SIP
Pages: 60
Informational
Informational
Part 3 of 4 – Pages 27 to 48
5.2. Basic NAT Media Traversal
This section provides example scenarios to demonstrate basic media traversal using the techniques outlined earlier in this document. In the flow diagrams, STUN messages have been annotated for simplicity as follows: o The "Src" attribute represents the source transport address of the message. o The "Dest" attribute represents the destination transport address of the message. o The "Map" attribute represents the server reflexive (XOR-MAPPED- ADDRESS STUN attribute) transport address. o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN attribute) transport address. The meaning of each STUN attribute is extensively explained in the core STUN [RFC5389] and TURN [RFC5766] specifications. A number of ICE SDP attributes have also been included in some of the examples. Detailed information on individual attributes can be obtained from the core ICE specification [RFC5245]. The examples also contain a mechanism for representing transport addresses. It would be confusing to include representations of network addresses in the call flows and would make them hard to follow. For this reason, network addresses will be represented using the following annotation. The first component will contain the representation of the client responsible for the address. For example, in the majority of the examples "L" (left client), "R" (right client), "NAT-PUB" (NAT public), "PRIV" (Private), and "STUN- PUB" (STUN public) are used. To allow for multiple addresses from the same network element, each representation can also be followed by a number. These can also be used in combination. For example, "L-NAT-PUB-1" would represent a public network address of the left- hand side NAT while "R-NAT-PUB-1" would represent a public network address of the right-hand side of the NAT. "L-PRIV-1" would represent a private network address of the left-hand side of the NAT while "R-PRIV-1" represents a private address of the right-hand side of the NAT.
It should also be noted that, during the examples, it might be appropriate to signify an explicit part of a transport address. This is achieved by adding either the '.address' or '.port' tag on the end of the representation -- for example, 'L-PRIV-1.address' and 'L-PRIV- 1.port'. The use of '$' signifies variable parts in example SIP messages.5.2.1. Endpoint-Independent NAT
This section demonstrates an example of a client both initiating and receiving calls behind an Endpoint-Independent NAT. An example is included for both STUN and ICE with ICE being the RECOMMENDED mechanism for media traversal. At this time, there is no reliable test to determine if a host is behind an Endpoint-Independent Filtering NAT or an Endpoint- Independent Mapping NAT [RFC5780], and the sort of failure that occurs in this situation is described in Section 5.2.2.1. For this reason, ICE is RECOMMENDED over the mechanism described in this section.5.2.1.1. STUN Solution
It is possible to traverse media through an Endpoint-Independent NAT using STUN. The remainder of this section provides simplified examples of the 'Binding Discovery' STUN as defined in [RFC5389]. The STUN messages have been simplified and do not include 'Shared Secret' requests used to obtain the temporary username and password.5.2.1.1.1. Initiating Session
The following example demonstrates media traversal through a NAT with Endpoint-Independent Mapping properties using the STUN 'Binding Discovery' usage. It is assumed in this example that the STUN client and SIP Client are co-located on the same physical machine. Note that some SIP signaling messages have been left out for simplicity.
Client NAT STUN [..]
Server
| | | |
|(1) BIND Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(2) BIND Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(3) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(4) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(5) BIND Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(6) BIND Req | |
| |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(7) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| | | |
|(8) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | |
| | | |
|(9)SIP INVITE | | | |----------------->| | | | | | | | |(10)SIP INVITE | | | |------------------------------------>| | | | | | | |(11)SIP 200 OK | | |<------------------------------------| | | | | |(12)SIP 200 OK | | | |<-----------------| | | | | | | |========================================================| |>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>| |========================================================| | | |========================================================| |<<<<<<<<<<<<Incoming Media sent to NAT-PUB-1<<<<<<<<<<<<| |========================================================| | | |========================================================| |>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>| |========================================================| | | |========================================================| |<<<<<<<<<<<<Incoming RTCP sent to NAT-PUB-2<<<<<<<<<<<<<| |========================================================| | | | | |(13)SIP ACK | | | |----------------->| | | | | | | | |(14) SIP ACK | | | |------------------------------------>| | | | | Figure 11: Endpoint-Independent NAT - Initiating o On deciding to initiate a SIP voice session, the client starts a local STUN client on the interface and port that is to be used for media (send/receive). The STUN client generates a standard 'Binding Discovery' request as indicated in (1) from Figure 11 that also highlights the source address and port for which the client device wishes to obtain a mapping. The 'Binding Discovery' request is sent through the NAT towards the public Internet and STUN server.
o Message (2) traverses the NAT and breaks out onto the public
Internet towards the public STUN server. Note that the source
address of the 'Binding Discovery' request now represents the
public address and port from the public side of the NAT.
o The STUN server receives the request and processes it
appropriately. This results in a successful 'Binding Discovery'
response being generated and returned (3). The message contains
details of the XOR-mapped public address (contained in the STUN
XOR-MAPPED-ADDRESS attribute) that is to be used by the
originating client to receive media (see 'Map=NAT-PUB-1' from
(3)).
o The 'Binding Discovery' response traverses back through the NAT
using the path created by the 'Binding Discovery' request and
presents the new XOR-mapped address to the client (4). At this
point, the process is repeated to obtain a second XOR-mapped
address (as shown in (5)-(8)) for a second local address (the
address has changed from "L-PRIV-1" to "L-PRIV-2") for an RTCP
port.
o The client now constructs a SIP INVITE message (9). Note that
traversal of SIP is not covered in this example and is discussed
in Section 5.1. The INVITE request will use the addresses it has
obtained in the previous STUN transactions to populate the SDP of
the SIP INVITE as shown below:
v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address
c=IN IP4 $NAT-PUB-1.address
t=0 0
m=audio $NAT-PUB-1.port RTP/AVP 0
a=rtcp:$NAT-PUB-2.port
o Note that the XOR-mapped address obtained from the 'Binding
Discovery' transactions are inserted as the connection address for
the SDP (c=$NAT-PUB-1.address). The Primary port for RTP is also
inserted in the SDP (m=audio $NAT-PUB-1.port RTP/AVP 0). Finally,
the port gained from the additional 'Binding Discovery' is placed
in the RTCP attribute (as discussed in Section 4.2.2) for
traversal of RTCP (a=rtcp:$NAT-PUB-2.port).
o The SIP signaling then traverses the NAT and sets up the SIP
session (9-12). Note that the left-hand client transmits media as
soon as the 200 OK to the INVITE arrives at the client (12). Up
until this point, the incoming media and RTCP to the left-hand
client will not pass through the NAT as no outbound association
has been created with the far-end client. Two-way media
communication has now been established.
5.2.1.1.2. Receiving Session Invitation
Receiving a session for an Endpoint-Independent NAT using the STUN
'Binding Discovery' usage is very similar to the example outlined in
Section 5.2.1.1.1. Figure 12 illustrates the associated flow of
messages.
Client NAT STUN [..]
Server
| | | (1)SIP INVITE |
| |<------------------------------------|
| | | |
|(2) SIP INVITE | | |
|<-----------------| | |
| | | |
|(3) BIND Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(4) BIND Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| |
| | | |
| |(5) BIND Resp | |
| |<-----------------| |
| |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(6) BIND Resp | | |
|<-----------------| | |
|Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(7) BIND Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB | | |
|----------------->| | |
| | | |
| |(8) BIND Req | | | |Src=NAT-PUB-2 | | | |Dest=STUN-PUB | | | |----------------->| | | | | | | |(9) BIND Resp | | | |<-----------------| | | |Src=STUN-PUB | | | |Dest=NAT-PUB-2 | | | |Map=NAT-PUB-2 | | | | | | |(10) BIND Resp | | | |<-----------------| | | |Src=STUN-PUB | | | |Dest=L-PRIV-2 | | | |Map=NAT-PUB-2 | | | | | | | |(11)SIP 200 OK | | | |----------------->| | | | |(12)SIP 200 OK | | | |------------------------------------>| | | | | |========================================================| |>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>| |========================================================| | | | | |========================================================| |<<<<<<<<<<<<<Incoming Media sent to L-PRIV-1<<<<<<<<<<<<| |========================================================| | | | | |========================================================| |>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>| |========================================================| | | | | |========================================================| |<<<<<<<<<<<<<Incoming RTCP sent to L-PRIV-2<<<<<<<<<<<<<| |========================================================| | | | | | | |(13)SIP ACK | | |<------------------------------------| | | | | |(14)SIP ACK | | | |<-----------------| | | | | | | Figure 12: Endpoint-Independent NAT - Receiving
o On receiving an invitation to a SIP voice session (SIP INVITE
request), the User Agent starts a local STUN client on the
appropriate port on which it is to receive media. The STUN client
generates a standard 'Binding Discovery' request as indicated in
(3) from Figure 12 that also highlights the source address and
port for which the client device wishes to obtain a mapping. The
'Binding Discovery' request is sent through the NAT towards the
public Internet and STUN server.
o 'Binding Discovery' message (4) traverses the NAT and breaks out
onto the public Internet towards the public STUN server. Note
that the source address of the STUN requests now represents the
public address and port from the public side of the NAT.
o The STUN server receives the request and processes it
appropriately. This results in a successful 'Binding Discovery'
response being generated and returned (5). The message contains
details of the mapped public address (contained in the STUN XOR-
MAPPED-ADDRESS attribute) that is to be used by the originating
client to receive media (see 'Map=NAT-PUB-1' from (5)).
o The 'Binding Discovery' response traverses back through the NAT
using the path created by the outgoing 'Binding Discovery' request
and presents the new XOR-mapped address to the client (6). At
this point, the process is repeated to obtain a second XOR-mapped
address (as shown in (7)-(10)) for a second local address (local
port has now changed and is represented by L-PRIV-2 in (7)) for an
RTCP port.
o The client now constructs a SIP 200 OK message (11) in response to
the original SIP INVITE requests. Note that traversal of SIP is
not covered in this example and is discussed in Section 5.1. SIP
Provisional responses are also left out for simplicity. The 200
OK response will use the addresses it has obtained in the previous
STUN transactions to populate the SDP of the SIP 200 OK as shown
below:
v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address
c=IN IP4 $NAT-PUB-1.address
t=0 0
m=audio $NAT-PUB-1.port RTP/AVP 0
a=rtcp:$NAT-PUB-2.port
o Note that the XOR-mapped address obtained from the initial
'Binding Discovery' transaction is inserted as the connection
address for the SDP (c=NAT-PUB-1.address). The Primary port for
RTP is also inserted in the SDP (m=audio NAT-PUB-1.port RTP/AVP
0). Finally, the port gained from the second 'Binding Discovery'
is placed in the RTCP attribute (as discussed in Section 4.2.2)
for traversal of RTCP (a=rtcp:NAT-PUB-2.port).
o The SIP signaling then traverses the NAT and sets up the SIP
session (11-14). Note that the left-hand client transmits media
as soon as the 200 OK to the INVITE is sent to the User Agent
Client (UAC) (11). Up until this point, the incoming media from
the right-hand client will not pass through the NAT as no outbound
association has been created with the far-end client. Two-way
media communication has now been established.
5.2.1.2. ICE Solution
The preferred solution for media traversal of NAT is using ICE, as
described in Section 4.2.3.3, regardless of the NAT type. The
following examples illustrate the traversal of an Endpoint-
Independent NAT when initiating the session. The example only covers
ICE in association with the 'Binding Discovery' and TURN. It is
worth noting that the TURN server provides both STUN functions (to
learn your public mapping) and TURN functions (media relaying). It
is also worth noting that in the example described in
Section 5.2.1.2.1, both SIP clients L and R are contacting the same
TURN server. This is not necessary for ICE, STUN, TURN to function;
all that is necessary is that the STUN and TURN server(s) be in the
same addressing domain that is accessible on the Internet.
5.2.1.2.1. Initiating Session
The following example demonstrates an initiating traversal through an
Endpoint-Independent NAT using ICE.
L NAT STUN NAT R
Server
| | | | |
|(1) Alloc Req | | | |
|Src=L-PRIV-1 | | | |
|Dest=TURN-PUB-1 | | | |
|--------------->| | | |
| | | | |
| |(2) Alloc Req | | |
| |Src=L-NAT-PUB-1 | | |
| |Dest=TURN-PUB-1 | | |
| |--------------->| | |
| | | | |
| |(3) Alloc Resp | | |
| |<---------------| | |
| |Src=TURN-PUB-1 | | |
| |Dest=L-NAT-PUB-1| | |
| |Map=L-NAT-PUB-1 | | |
| |Rel=TURN-PUB-2 | | |
| | | | |
|(4) Alloc Resp | | | |
|<---------------| | | |
|Src=TURN-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
|Rel=TURN-PUB-2 | | | |
| | | | |
|(5) Alloc Req | | | |
|Src=L-PRIV-2 | | | |
|Dest=TURN-PUB-1 | | | |
|--------------->| | | |
| | | | |
| |(6) Alloc Req | | |
| |Src=L-NAT-PUB-2 | | |
| |Dest=TURN-PUB-1 | | |
| |--------------->| | |
| | | | |
| |(7) Alloc Resp | | |
| |<---------------| | |
| |Src=TURN-PUB-1 | | |
| |Dest=NAT-PUB-2 | | |
| |Map=NAT-PUB-2 | | |
| |Rel=TURN-PUB-3 | | |
| | | | |
|(8) Alloc Resp | | | |
|<---------------| | | |
|Src=TURN-PUB-1 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
|Rel=TURN-PUB-3 | | | |
| | | | |
|(9) SIP INVITE | | | |
|------------------------------------------------->| |
| | | | |
| | | |(10) SIP INVITE |
| | | |--------------->|
| | | | |
| | | |(11) Alloc Req |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=TURN-PUB-1 |
| | | | |
| | |(12) Alloc Req | |
| | |<---------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=TURN-PUB-1 | |
| | | | |
| | |(13) Alloc Res | |
| | |--------------->| |
| | |Src=TURN-PUB-1 | |
| | |Dest=R-NAT-PUB-1| |
| | |Map=R-NAT-PUB-1 | |
| | |Rel=TURN-PUB-4 | |
| | | | |
| | | |(14) Alloc Res |
| | | |--------------->|
| | | |Src=TURN-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |Map=R-NAT-PUB-1 |
| | | |Rel=TURN-PUB-4 |
| | | | |
| | | |(15) Alloc Req |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=TURN-PUB-1 |
| | | | |
| | |(16) Alloc Req | |
| | |<---------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=TURN-PUB-1 | |
| | | | |
| | |(17) Alloc Res | |
| | |--------------->| |
| | |Src=TURN-PUB-1 | |
| | |Dest=R-NAT-PUB-2| |
| | |Map=R-NAT-PUB-2 | |
| | |Rel=TURN-PUB-5 | |
| | | | |
| | | |(18) Alloc Res |
| | | |--------------->|
| | | |Src=TURN-PUB-1 |
| | | |Dest=R-PRIV-2 |
| | | |Map=R-NAT-PUB-2 |
| | | |Rel=TURN-PUB-5 |
| | | | |
| | | |(19) SIP 200 OK |
| |<-------------------------------------------------|
| | | | |
|(20) SIP 200 OK | | | |
|<---------------| | | |
| | | | |
|(21) SIP ACK | | | |
|------------------------------------------------->| |
| | | | |
| | | |(22) SIP ACK |
| | | |--------------->|
| | | | |
|(23) Bind Req | | | |
|------------------------>x | | |
|Src=L-PRIV-1 | | | |
|Dest=R-PRIV-1 | | | |
| | | | |
|(24) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
| | | | |
| |(25) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| | | | |
| | | |(26) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | | |
| | | |(27) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | |Map=L-NAT-PUB-1 |
| | | | |
| | |(28) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | |Map=L-NAT-PUB-1 | |
| | | | |
|(29) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
| | | | |
|===================================================================|
|>>>>>>>>>>>>>>>>>>Outgoing RTP sent from L-PRIV-1 >>>>>>>>>>>>>>>>>|
|===================================================================|
| | | | |
| | | |(30) Bind Req |
| | | x<-----------------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-PRIV-1 |
| | | | |
| | | |(31) Bind Req |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | | |
| | |(32) Bind Req | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | | | |
|(33) Bind Req | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
| | | | |
|(34) Bind Res | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
|Map=R-NAT-PUB-1 | | | |
| | | | |
| |(35) Bind Res | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| |Map=R-NAT-PUB-1 | | |
| | | | |
| | | |(36) Bind Res |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |Map=R-NAT-PUB-1 |
| | | | |
|===================================================================|
|<<<<<<<<<<<<<<<<<<Outgoing RTP sent from R-PRIV-1 <<<<<<<<<<<<<<<<<|
|===================================================================|
|(37) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
|USE-CANDIDATE | | | |
| | | | |
| |(38) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| |USE-CANDIDATE | | |
| | | | |
| | | |(39) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |USE-CANDIDATE |
| | | | |
| | | |(40) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | |Map=L-NAT-PUB-1 |
| | | | |
| | |(41) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | |Map=L-NAT-PUB-1 | |
| | | | |
|(42) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
| | | | |
|(43) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
| | | | |
| |(44) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| | | | |
| | | |(45) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | | |
| | | |(46) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | |Map=L-NAT-PUB-2 |
| | | | |
| | |(47) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | |Map=L-NAT-PUB-2 | |
| | | | |
|(48) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
| | | | |
|===================================================================|
|>>>>>>>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2 >>>>>>>>>>>>>>>>|
|===================================================================|
| | | | |
| | | |(49) Bind Req |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | | |
| | |(50) Bind Req | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | | | |
|(51) Bind Req | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
| | | | |
|(52) Bind Res | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
|Map=R-NAT-PUB-2 | | | |
| | | | |
| |(53) Bind Res | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| |Map=R-NAT-PUB-2 | | |
| | | | |
| | | |(54) Bind Res |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | |Map=R-NAT-PUB-2 |
| | | | |
|===================================================================|
|<<<<<<<<<<<<<<<<<<Outgoing RTCP sent from R-PRIV-2<<<<<<<<<<<<<<<<<|
|===================================================================|
|(55) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
|USE-CANDIDATE | | | |
| | | | |
| |(56) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| |USE-CANDIDATE | | |
| | | | |
| | | |(57) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | |USE-CANDIDATE |
| | | | | | | | |(58) Bind Res | | | | |<---------------| | | | |Src=R-PRIV-2 | | | | |Dest=L-NAT-PUB-2| | | | |Map=L-NAT-PUB-2 | | | | | | | | |(59) Bind Res | | | |<--------------------------------| | | | |Src=R-NAT-PUB-2 | | | | |Dest=L-NAT-PUB-2| | | | |Map=L-NAT-PUB-2 | | | | | | | |(60) Bind Res | | | | |<---------------| | | | |Src=R-NAT-PUB-2 | | | | |Dest=L-PRIV-2 | | | | |Map=L-NAT-PUB-2 | | | | | | | | | | | | | | |(61) SIP INVITE | | | | |------------------------------------------------->| | | | | | | | | | |(62) SIP INVITE | | | | |--------------->| | | | | | | | | |(63) SIP 200 OK | | |<-------------------------------------------------| | | | | | |(64) SIP 200 OK | | | | |<---------------| | | | | | | | | |(65) SIP ACK | | | | |------------------------------------------------->| | | | | | | | | | |(66) SIP ACK | | | | |--------------->| | | | | | Figure 13: Endpoint-Independent NAT with ICE o On deciding to initiate a SIP voice session, the SIP client L starts a local STUN client. The STUN client generates a TURN Allocate request as indicated in (1) from Figure 13 that also highlights the source address and port combination for which the client device wishes to obtain a mapping. The Allocate request is sent through the NAT towards the public Internet.
o The Allocate message (2) traverses the NAT to the public Internet
towards the public TURN server. Note that the source address of
the Allocate request now represents the public address and port
from the public side of the NAT (L-NAT-PUB-1).
o The TURN server receives the Allocate request and processes it
appropriately. This results in a successful Allocate response
being generated and returned (3). The message contains details of
the server reflexive address that is to be used by the originating
client to receive media (see 'Map=L-NAT-PUB-1') from (3)). It
also contains an appropriate TURN-relayed address that can be used
at the STUN server (see 'Rel=TURN-PUB-2').
o The Allocate response traverses back through the NAT using the
binding created by the initial Allocate request and presents the
new mapped address to the client (4). The process is repeated and
a second STUN derived set of addresses is obtained, as illustrated
in (5)-(8) in Figure 13. At this point, the User Agent behind the
NAT has pairs of derived external server reflexive and relayed
representations. The client can also gather IP addresses and
ports via other mechanisms (e.g., NAT-PMP [NAT-PMP], UPnP IGD
[UPnP-IGD]) or similar.
o The client now constructs a SIP INVITE message (9). The INVITE
request will use the addresses it has obtained in the previous
STUN/TURN interactions to populate the SDP of the SIP INVITE.
This should be carried out in accordance with the semantics
defined in the ICE specification [RFC5245], as shown below in
Figure 14:
v=0 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1 c=IN IP4 $L-PRIV-1.address t=0 0 a=ice-pwd:$LPASS a=ice-ufrag:$LUNAME m=audio $L-PRIV-1.port RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=rtcp:$L-PRIV-2.port a=candidate:$L1 1 UDP 2130706431 $L-PRIV-1.address $L-PRIV-1.port typ host a=candidate:$L1 2 UDP 2130706430 $L-PRIV-2.address $L-PRIV-2.port typ host a=candidate:$L2 1 UDP 1694498815 $L-NAT-PUB-1.address $L-NAT-PUB-1.port typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port a=candidate:$L2 2 UDP 1694498814 $L-NAT-PUB-2.address $L-NAT-PUB-2.port typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-2.port typ relay raddr $L-PRIV-1.address rport $L-PRIV-1.port a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-3.port typ relay raddr $L-PRIV-1.address rport $L-PRIV-2.port Figure 14: ICE SDP Offer o The SDP has been constructed to include all the available candidates that have been assembled. The first set of candidates (as identified by Foundation $L1) contains two local addresses that have the highest priority. They are also encoded into the connection (c=) and media (m=) lines of the SDP. The second set of candidates, as identified by Foundation $L2, contains the two server reflexive addresses obtained from the STUN server for both RTP and RTCP traffic (identified by candidate-id $L2). This entry has been given a priority lower than the pair $L1 by the client. The third and final set of candidates represents the relayed addresses (as identified by $L3) obtained from the STUN server. This pair has the lowest priority and will be used as a last resort if both $L1 and $L2 fail. o The SIP signaling then traverses the NAT and sets up the SIP session (9)-(10). On advertising a candidate address, the client should have a local STUN server running on each advertised candidate address. This is for the purpose of responding to incoming STUN connectivity checks. o On receiving the SIP INVITE request (10) client R also starts local STUN servers on appropriate address/port combinations and gathers potential candidate addresses to be encoded into the SDP (as the originating client did). Steps (11-18) involve client R
carrying out the same steps as client L. This involves obtaining
local, server reflexive, and relayed addresses. Client R is now
ready to generate an appropriate answer in the SIP 200 OK message
(19). The example answer follows in Figure 15:
v=0
o=test 3890844516 3890842803 IN IP4 $R-PRIV-1
c=IN IP4 $R-PRIV-1.address
t=0 0
a=ice-pwd:$RPASS
m=audio $R-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rtcp:$R-PRIV-2.port
a=candidate:$L1 1 UDP 2130706431 $R-PRIV-1.address $R-PRIV-1.port
typ host
a=candidate:$L1 2 UDP 2130706430 $R-PRIV-2.address $R-PRIV-2.port
typ host
a=candidate:$L2 1 UDP 1694498815 $R-NAT-PUB-1.address $R-NAT-PUB-1.port
typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L2 2 UDP 1694498814 $R-NAT-PUB-2.address $R-NAT-PUB-2.port
typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-4.port
typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-5.port
typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port
Figure 15: ICE SDP Answer
o The two clients have now exchanged SDP using offer/answer and can
now continue with the ICE processing -- User Agent L assuming the
role controlling agent, as specified by ICE. The clients are now
required to form their Candidate check lists to determine which
will be used for the media streams. In this example, User Agent
L's Foundation 1 is paired with User Agent R's Foundation 1, User
Agent L's Foundation 2 is paired with User Agent R's Foundation 2,
and finally User Agent L's Foundation 3 is paired with User Agent
R's Foundation 3. User Agents L and R now have a complete
candidate checklist. Both clients now use the algorithm provided
in ICE to determine candidate pair priorities and sort into a list
of decreasing priorities. In this example, both User Agents L and
R will have lists that firstly specify the host address
(Foundation $L1), then the server reflexive address (Foundation
$L2), and lastly the relayed address (Foundation $L3). All
candidate pairs have an associate state as specified in ICE. At
this stage, all of the candidate pairs for User Agents L and R are
initialized to the 'Frozen' state. The User Agents then scan the
list and move the candidates to the 'Waiting' state. At this
point, both clients will periodically, starting with the highest
candidate pair priority, work their way down the list issuing STUN
checks from the local candidate to the remote candidate (of the
candidate pair). As a STUN check is attempted from each local
candidate in the list, the candidate pair state transitions to
'In-Progress'. As illustrated in (23), client L constructs a STUN
connectivity check in an attempt to validate the remote candidate
address received in the SDP of the 200 OK (20) for the highest
priority in the checklist. As a private address was specified in
the active address in the SDP, the STUN connectivity check fails
to reach its destination causing a STUN failure. Client L
transitions the state for this candidate pair to 'Failed'. In the
meantime, client L is attempting a STUN connectivity check for the
second candidate pair in the returned SDP with the second highest
priority (24). As can be seen from messages (24) to (29), the
STUN Bind request is successful and returns a positive outcome for
the connectivity check. Client L is now free to send media to the
peer using the candidate pair. Immediately after sending its 200
OK, client R also carries out the same set of binding requests.
It firstly (in parallel) tries to contact the active address
contained in the SDP (30) which results in failure.
o In the meantime, a successful response to a STUN connectivity
check by User Agent R (27) results in a tentative check in the
reverse direction -- this is illustrated by messages (31) to (36).
Once this check has succeeded, User Agent R can transition the
state of the appropriate candidate to 'Succeeded', and media can
be sent (RTP). The previously (31-36) described check confirm on
both sides (User Agents L and R) that connectivity can be achieved
using the appropriate candidate pair. User Agent L, as the
controlling client now sends another connectivity check for the
candidate pair, this time including the 'USE-CANDIDATE' attribute
as specified in ICE to signal the chosen candidate. This exchange
is illustrated in messages (37) to (42).
o As part of the process in this example, both L and R will now
complete the same connectivity checks for part 2 of the component
named for the favored 'Foundation' selected for use with RTCP.
The connectivity checks for part 2 of the candidate component are
shown in L (43-48) and R (49-54). Once this has succeeded, User
Agent L as the controlling client sends another connectivity check
for the candidate pair. This time the 'USE-CANDIDATE' attribute
is again specified to signal the chosen candidate for component 2.
o The candidates have now been fully verified (and selected), and as
they are the highest priority, an updated offer (61-62) is now
sent from the offerer (client L) to the answerer (client R)
representing the new active candidates. The new offer would look
as follows:
v=0 o=test 2890844526 2890842808 IN IP4 $L-PRIV-1 c=IN IP4 $L-NAT-PUB-1.address t=0 0 a=ice-pwd:$LPASS a=ice-ufrag:$LUNAME m=audio $L-NAT-PUB-1.port RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=rtcp:$L-NAT-PUB-2.port a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port Figure 16: ICE SDP Updated Offer o The resulting answer (63-64) for R would look as follows: v=0 o=test 3890844516 3890842804 IN IP4 $R-PRIV-1 c=IN IP4 $R-PRIV-1.address t=0 0 a=ice-pwd:$RPASS a=ice-ufrag:$RUNAME m=audio $R-PRIV-1.port RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=rtcp:$R-PRIV-2.port a=candidate:$L2 1 UDP 2984756463 $R-NAT-PUB-1.address $R-NAT-PUB-1.port typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port typ srflx raddr $R-PRIV-1.address rport $R-PRIV-2.port Figure 17: ICE SDP Updated Answer
(page 48 continued on part 4)