hi,

generally, the UA doesn't put its private port unless there is a NAT ALG which 
translates them... 

it generally asks before for public address and ports. Some technics exist 
which are called turn, stun, ice... etc.... moreover there is some technics to 
treat the case of signalisation stream ! it s too a problem for them because it 
s difficult for them to pass through nats !

 

u can find below the bibliography i use to understand how work nats. 

 

1.         TEREDO Overview. Microsoft TechNet, Janvier 2003.

2.         Srisuresh, P., Holdrege, M., IP Network Address Translator (NAT) 
Terminology and Considerations. IETF RFC 2663, Août 1999.

3.         Hain, T., Architectural Implications of NAT. IETF RFC 2993, November 
2000.

4.         Elkik, A., Garanto, H., Porquet, J., VAD/DTX : Techniques de base et 
intérêts pratiques.

5.         Rosenberg, J., Weinberger, J., Huitema, C., Mahy, R., STUN - Simple 
Traversal of User Datagram Protocol (UDP) Through Network Address Translators 
(NATs). IETF RFC 3489, March 2003.

6.         Mächler, P., SIP Architecture with NAT Version 1.0. Mai 2004.

7.         Audet, F., Nortel, Ed., Jennings, C., NAT Behavioral Requirements 
for Unicast UDP. IETF Draft draft-ietf-behave-nat-udp-00.txt (Work in 
Progress), Janvier 2005.

8.         Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 
Peterson, J., Sparks, R., Handley, M., Schooler, E., SIP : Session Initiation 
Protocol. IETF RFC 3261, Juin 2002.

9.         Paulsamy, V., Chatterjee, S., Network Convergence and the 
NAT/Firewall Problems. IEEE, 2002.

10.       Boulton, C., Rosenberg, J., Best Current Practices for NAT Traversal 
for SIP. IETF Draft draft-ietf-sipping-nat-scenarios-02 (Work in Progress), 
Octobre 2004.

11.       Rosenberg, J., Schulzrinne, H., An Extension to the Session 
Initiation Protocol (SIP) for Symmetric Response Routing. IETF RFC 3581, August 
2003.

12.       Jennings, C., Hawrylyshen, A., SIP Conventions for UAs with Outbound 
Only Connections. IETF Draft draft-jennings-sipping-outbound-01 (Work in 
Progress), Février 2005.

13.       Mahy, R., Connection Reuse in the Session Initiation Protocol (SIP). 
IETF Draft draft-ietf-sip-connect-reuse-03.txt (Work in Progress), Octobre 2004.

14.       Bhatia, M., Ramachandran, S., Kulshreshtha, G., Devdhar, R., SIP 
Session Border Control Requirements. IETF Draft draft-bhatia-sipping-sbc-00 
(Work in Progress), Janvier 2005.

15.       Camarillo, G., Hautakorpi, J., Penfield, R., Hawrylyshen, A., 
Functionality of Existing Session Border Controller (SBC). IETF Draft 
draft-camarillo-sipping-sbc-funcs-00 (Work in Progress), Février 2005.

 

17.       Rosenberg, J., Mahy, R., Huitema, C., Traversal Using Relay NAT 
(TURN). IETF Draft draft-rosenberg-midcom-turn-07 (Work in Progress), Février 
2005.

18.       Rosenberg, J., Interactive Connectivity Establishment (ICE) : A 
Methodology for Network Address Translator (NAT) Traversal  for Multimedia 
Session Establishment Protocols. IETF Draft draft-ietf-mmusic-ice-04  (Work in 
Progress), Février 2005.

19.       A Technical Guide to UPnP. 2003, Allied Telesyn International, Corp.

20.       Kolic, R., The Advantages of the UPnP* Internet Gateway Device. Intel 
Developer UPDATE Magazine, Janvier 2002.

21.       Poulidis, P., Internet Gateway Device (IGD), UPnP Forum.

22.       Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., Rayhan, A., 
Middlebox Communications architecture and framework. IETF RFC 3303, Août 2002.

23.       Swale, R.P., Mart, P. A., Sijben, P., Brim, S., Shore, M., Middlebox 
Communications (midcom) Protocol Requirements. IETF RFC 3304, Août 2000.

24.       Stiemerling, M., Quittek, J., Taylor, T., Middlebox Communications 
(MIDCOM) Protocol Semantics. IETF RFC 3989, Février 2005.

25.       Yon, D., Connection-Oriented Media Transport. IETF Draft 
Draft-ietf-mmusic-sdp-comedia-05.txt (Work in Progress), Septembre 2003.

26.       Yon, D., Camarillo, G., TCP-Based Media Transport in the Session 
Description Protocol. IETF Draft draft-ietf-mmusic-sdp-comedia-10 (Work in 
Progress), Novembre 2004.

27.       Wing, D., Symmetric RTP and RTCP Considered Helpful. IETF Draft 
draft-wing-mmusic-symmetric-rtprtcp-01 (Work in Progress), Octobre 2004.

28.       Huitema, C., Real Time Control Protocol (RTCP) attribute in Session 
Description Protocol (SDP). IETF RFC 3605, Octobre 2003.

29.       Rosenberg, J., Best Current Practices for NAT Traversal for SIP. IETF 
Draft draft-ietf-sipping-nat-scenarios-01 (Work in Progress), Octobre 2004.

30.       Rosenberg, J., NAT traversal Considerations. IETF Draft 
draft-iab-nat-traversal-considerations-00 (Work in Progress), Août 2004.

 

Arnault


[EMAIL PROTECTED] a écrit :

Hi Arnault,

I am jotting down a scenario here. Tell me if it is wrong.

1. Invite is send with SDP with private parameters for rtp and rtcp.
2. NAT probe can't be connected because RTP and RTCP port of external party is 
not known.
3. external party sends 200OK with its rtp and rtcp port(optional).
4. NAT probe is contacted to get external mapping of RTP and RTCP port.
5. ACK is sent with updated mapped RTP and RTCP port in SDP.

Cheers,
Vivek

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arnault Nagle
Sent: Monday, July 04, 2005 7:00 PM
To: [email protected]
Subject: RE: [Sip-implementors] NAT traversal in SIP


and of course, u must ask before the nat to give u another port (and even IP 
address if u need !!)

Arnault Nagle a écrit :hello,

this answer is in Huitema, C., Real Time Control Protocol (RTCP) attribute in 
Session Description Protocol (SDP). IETF RFC 3605, Octobre 2003

you can specify the port ofor the RTCP packets.

c=IN IP4 1.2.3.4

m=audio 14567 RTP/AVP 0

a=rtcp:23456

++



Arnault




[EMAIL PROTECTED] a écrit :

Hi All,

I have a query related with NAT traversal in SIP. In case of restricted
cone and port restricted cone, SIP ua1 connect to NAT probe to get it
external address. Consider the case when UA1 knows that its internal RTP
ip:port which is 10.0.0.1:8000 and NAT probe gives external ip:port
205.205.205.205:1234. Now SIP UA will send c=205.205.205.205 and m =
AUDIO 1234 in SDP. With this information other end UA2 will be able to
send RTP packet on 1234 of NAT which will lend successfully on 8000 of
SIP UA1. But SIP UA1 will open 8001 for RTCP and UA2 will assume 1235 is
RTCP port for UA1. In this case how 2 way media path is established? I
know external query works for restricted cone and port restricted cone
NAT then am i missing something?

Cheers,

Vivek





Confidentiality Notice

The information contained in this electronic message and any attachments to 
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or 
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or [EMAIL 
PROTECTED] immediately
and destroy all copies of this message and any attachments.
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


---------------------------------
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez le ici !


---------------------------------
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez le ici ! 
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors



Confidentiality Notice

The information contained in this electronic message and any attachments to 
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or 
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or [EMAIL 
PROTECTED] immediately
and destroy all copies of this message and any attachments.

                
---------------------------------
 Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
 Téléchargez le ici !  
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to