One document matched: draft-sen-sipping-intrarealm-stun-00.txt
SIPPING Working Group S. Sen
Internet Draft F. Audet
F Meijer
C. Aoun
Category: Informational Nortel Networks
Expires on March 2003 Sept 2002
Identifying Intra-realm Calls using STUN
<draft-sen-sipping-intrarealm-stun-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This draft proposes the use of STUN to determine whether two communicating
endpoints are in the same realm. This draft describes the use of STUN in a peer-
to-peer fashion between endpoints during call set-up. The call set-up may proceed
in parallel with the STUN messaging, allowing the peers to initially exchange
media using their public IP addresses. If the peers are in the same realm, then
the media is switched to the private IP addresses using a SIP UPDATE or a SIP
reINVITE SDP offer-answer exchange. With this proposal, media flows are kept
within the same addressing realm whenever possible, thus avoiding certain network
intermediaries and reducing bandwidth requirements on external links into the
realm.
1 Introduction
This draft proposes the use of [STUN] to identify if two communicating endpoints
are in the same realm. Using this proposal, media flows are kept within the same
Sen [Page 1]
Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002
addressing realm whenever possible, thus avoiding usage of certain network
intermediaries and reducing bandwidth requirements on external links into the
realm. In a typical usage of STUN without the implementation of this proposal, two
endpoints behind a NAT would send their media through the NAT even in the scenario
where there is a direct path. This requires that the NAT loop back the media
packets. This loop back approach is an inefficient use of resources and it may not
be supported by all types of NATs. Thus, a simple, scalable and secure mechanism
at the endpoints to detect this direct connectivity is required. This draft
describes how STUN can be used in a peer-to-peer fashion along with the SIP session
setup to detect intra-realm sessions.
1.1 Applicability
The solution applies to the simple topology where there are one or more
NATs between the endpoints that do not share a common root NAT. A more
general case, typical of many cable service providers, is when the clients
are behind NATs that are all connected to a NAT in the service provider
network. The solution for this general case is NOT addressed by this memo.
2 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
3 Terminology Used
Middle Box - refer to the terminology used in [FRMWRK]
Tromboning: The NAT loops back packets sent from a client addressed to the
public address of another client in the same realm behind the NAT
4 Motivation
Figure 1 shows a complex partitioned intranet in a large Enterprise. Users at
finance.us.x.com and finance.europe.x1.com are connected through the intranet
and does not have to traverse the NATÆs (MB1 and MB4 in Fig 1). Similarly,
calls between eng.europe.x.com and finance.europe.x1.com can be routed
directly, instead of going through MB4 and MB3. In a more traditional use of
STUN, users in finance.us.x.com would contact an external STUN server and
receive a public address at the NAT MB1. The users in finance.europe.x1.com
will similarly receive its public address on NAT MB4. The packets will be
exchanged using these public addresses through the Internet although there is
a direct path between the endpoints. This will generally lead to QoS
degradation, unnecessarily overload the middleboxes and/or involve an
intermediary when one is not required.
+++++++++++++++++++ ++++++++++++++++ +++++++
+finance.us.x.com + + +
+ + + Internet +----STUN Server 1
Sen Informational - Expires March 2003 [Page 2]
Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002
+ ++++++ + +
+ +MB1 +-----+ +
+ ++++++ + +
+++++++++++++++++++ + +-----STUN server n
| ++++++++++++++++ +++++++
| / |
| / |
| ++++++++++++++++++ |
| + +MB3+ + |
| + +++++ + |
| +eng.europe.x.com+ |
| + + |
| ++++++++++++++++++ |
| | | |
+++++++++++++ ++++++++++++++++++++++++++++
+ x.com + + +MB4+ +
+ Intranet + + +++++ +
+ +---+ +
+++++++++++++ + finance.europe.x1.com +
+++++++++++++++++++++++++++
Figure 1.
In case of a session between users behind the same Middlebox, the packets
exchanged between the two endpoints need to be looped back by the
Middlebox. This feature is called ætromboningÆ and is not supported by all
types of NATÆs. Therefore, if the Middlebox does not support tromboning, a
Middlebox traversal solution based on STUN will fail.
It is of advantage, in the above scenarios, for the media endpoints to
automatically detect whether there is any direct connectivity between them.
5 Solution
The solution requires the endpoints to support both STUN client and server.
The STUN server at the endpoints need to listen at address and port that is
bound to its publicly advertised media address and port. The endpoints will
exchange STUN probes in a peer-to-peer fashion before the media session is
established to discover if there is any direct connectivity between them.
The mechanism is illustrated with an example for user A establishing a
session with user B using SIP (please refer to Fig 2 for an example flow).
The same methodology could be done with other application protocols.
1) User A sends a SIP INVITE [Fig 2-(1)] with a Require: header with a new
option tag ôconndetect-stunö. It is assumed that the INVITE contains an SDP
carrying the public address and port (Pub-A) at which A wants to receive
media.
2) Upon receipt of AÆs SDP, B sends two STUN BINDING_REQUEST messages to
Pub-A. One of the BINDING_REQUEST messages will have its RESPONSE-ADDRESS
Sen Informational - Expires March 2003 [Page 3]
Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002
attribute set to the private IP address and port at B (Pvt-B) [Fig 2-(3)].
This is the private address/port at which B wishes to receive media. The
other BINDING_REQUEST message MUST NOT contain a RESPONSE-ADDRESS attribute
[Fig 2-(2)]. The two messages MUST contain different transaction IDs.
3) User A will respond to both the BINDING_REQUEST messages in the order
that they are received [Fig 2-(4), Fig 2-(5)]. The BINDING_RESPONSE message
in response to the request containing the RESPONSE_ADDRESS will be sent to
the address Pvt-B [Fig 2-(5)].
4) Based on the network connectivity between the two users, user B receives
either (a) 2 BINDING_RESPONSES, or (b) 1 BINDING_RESPONSE, or (c) no
BINDING_RESPONSE.
Case (a) will happen when both users A and B are behind the same NAT and
the NAT supports tromboning.
Case (b) will happen when the users are in different realms (behind
different NATÆs).
Case (c) can happen only if the two users are behind the same NAT and the
NAT does not support tromboning.
If user B does not receive any BINDING_RESPONSE message then the
retransmission mechanism in [STUN] is invoked. If no BINDING_RESPONSE is
received, client B concludes that A and B are in the same realm.
ISSUE: The real-time implication for this procedure needs to be further
evaluated based on real network deployments. Are there any scenarios
where this conclusion may not be correct?
If the first BINDING_RESPONSE is received and it matches the transaction id
of the BINDING_REQUEST that carried the RESPONSE-ADDRESS parameter, then B
concludes that A and B are in the same realm and goes to step 5. If the
transaction id of the first received BINDING_RESPONSE message matches that
of the request not carrying the RESPONSE-ADDRESS parameter, client B waits
for a timer period TNEXT (TBD) for the second BINDING_RESPONSE message. If
B receives the second BINDING_RESPONSE message within this period, it
concludes that the peer is in the same realm. If TNEXT expires, then it
concludes that A and B are in different realms (behind different NATÆs).
ISSUE: In case the endpoints are behind the same NAT and the NAT doesnÆt
support tromboning, then media packets will be lost until the direct
connectivity is detected and the endpoint addresses are updated. The
value of TNEXT will be motivated, in this scenario, by how long the users
will typically wait before they decide to terminate the session.
5) If user B determines (using the procedures in step 4) that its peer
(user A) is in the same realm, then it sends an UPDATE [Fig 2-(8)] message
(or a reINVITE, as appropriate) containing the private IP address and port
at which it wants to receive media
6) User A, on receiving an SDP from B (e.g., either in 18x or 200 OK
response to INVITE) [Fig 2-(6)], performs the exact same procedures [Fig 2-
(7)] as B does in steps 2 to 5 to determine direct connectivity. If user A
Sen Informational - Expires March 2003 [Page 4]
Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002
determines that B and A are in the same realm, then it responds differently
based on whether it has received an UPDATE (or reINVITE) from B, as
follows:
I) If A has received an UPDATE (or reINVITE) from B, then it
responds with 200 OK [Fig 2-(9)] specifying its private IP
address/port in the same m= line and c= line in the SDP where it
had originally specified a public address/port. A continues to
listen to its private address/port for the media.
II) If A have not received an UPDATE (or reINVITE) from B, then it
sends an UPDATE (or reINVITE) to B specifying its private IP
address/port in the same m= line and c= line in the SDP where it
had originally specified a public address/port. A continues to
listen to its private address/port for the media.
When any of the users receives an SDP offer (or SDP answer) with a new
address/port for the media, it MUST start sending media to this updated
address/port.
7) The original INVITE transaction is ended by an ACK [Fig 2-(10)] and
media transmission begins.
NOTES-1) All the steps described above are not sequential. For example, A
can begin its intra-realm determination right after it receives a 200OK or
18x message containing an SDP from B, almost simultaneously to BÆs
determination of the same (step 4).
NOTES-2) The endpoints can start exchanging media through their publicly
addressed IP address/port after the dialog (or early dialog) is established
(e.g., after the INVITE/200OK or INVITE/18x exchange). After the
connectivity detection takes place, the endpoints are expected switch to
the new destination addresses.
6 An Example Call Flow
Scenario: The users are in the same realm and NAT supports tromboning
UAC / UAS / NAT
STUN client/server STUN client/server
private=10.0.1.1 private=10.0.2.2
public=1.2.3.4 public=1.2.4.5
| | |
|(1) INVITE | |
|Require:conndetect-stun |
|rtp=1.2.3.4:5679 | |
| | |
|------------------>| |
| | |
| |(2) STUN Bind Req |
| |src=10.0.2.2:5306 |
| |dest=1.2.3.4:5679 |
| |------------------>|
| |(2) STUN Bind Req |
| |src=1.2.4.5:5300 |
| |dest=10.0.1.1:5600 |
Sen Informational - Expires March 2003 [Page 5]
Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002
|<--------------------------------------|
| | |
| | |
| |(3) STUN Bind Req |
| |src=10.0.2.2:5306 |
| |dest=1.2.3.4:5679 |
| |Response_addr=10.0.2.2:5306
| |------------------>|
| |(3) STUN Bind Req |
| |src=1.2.4.5:5300 |
| |dest=10.0.1.1:5600 |
| |Response_addr=10.0.2.2:5306
|<--------------------------------------|
| | |
| | |
| (4) STUN Resp. | |
| src=10.0.1.1:5600 | |
| dst=1.2.4.5:5300 | |
| Mapped_Addr=1.2.4.5:5300 |
|-------------------------------------->|
| | |
| |(4) STUN Resp. |
| | src=1.2.3.4:5679 |
| | dst=10.0.2.2:5306 |
| | Mapped_Addr=1.2.4.5:5300
| |<------------------|
| | |
| (5) STUN Resp. | |
| src=10.0.1.1:5600 | |
| dst=10.0.2.2:5306 | |
| Mapped_Addr=1.2.4.5:5300 |
|------------------>| |
| | |
|(6) 200 OK | |
|rtp=1.2.4.5:6000 | |
|<------------------| |
| | |
|----> (7) | |
| | |
| (8) UPDATE | |
| rtp=10.0.2.2:5306 |
|<------------------| |
| | |
| (9) 200 OK | |
| rtp=10.0.1.1:5600 |
|------------------>| |
|(10) ACK | |
|------------------>| |
| | |
|<=================>| |
media
Sen Informational - Expires March 2003 [Page 6]
Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002
Figure 2.
7 References
[FRMWRK] Srisuresh, Kuthan, Rosenberg, Molitor, Rayhan,
"MIDCOM Architecture & Framework",
RFC 3303
[STUN] Rosenberg,Weinberger,Huitema,Mahy,
"STUN - Simple Traversal of UDP Through NATs",
Internet draft, draft-rosenberg-midcom-stun-02.txt
[OA] RFC 3264, ôAn Offer/Answer Model with SDPö
8 Acknowledgments
The author would like to thank the following people for their useful
comments and suggestions related to this draft:
9 Authors' Address
{sanjoy, audet, meijer, aoun}@nortelnetworks.com
10 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
11 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
Sen Informational - Expires March 2003 [Page 7]
Internet Draft draft-sen-sipping-intrarealm-00.txt Sept 2002
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
Sen Informational - Expires March 2003 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 00:38:01 |