> The excellent I-D <draft-ietf-sipping-nat-scenarios-07> shows 
> the ICE call flow with two endpoints behind two NAT (Fig. 22 
> on page 38) require 66 messages just for the SIP INVITE!
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sce
> narios-07.txt 

That figure does not show 66 messages.

That figure is clearly showing how the STUN messages are NATted,
which leads to an incorrect conclusion around the number of 
messages.  Specifically, for example, it shows this message
exchange which might be counted as "four messages"; yet, there
are only two messages (the allocate request and the allocate
response), which are NATted:

   L               NAT             STUN              
                                   Server
   |                |                |               
   |(1) Alloc Req   |                |               
   |Src=L-PRIV-1    |                |               
   |Dest=STUN-PUB-1 |                |               
   |--------------->|                |               
   |                |                |               
   |                |(2) Alloc Req   |               
   |                |Src=L-NAT-PUB-1 |               
   |                |Des=STUN-PUB-1  |               
   |                |--------------->|               
   |                |                |               
   |                |(3) Alloc Resp  |               
   |                |<---------------|               
   |                |Src=STUN-PUB-1  |               
   |                |Dest=L-NAT-PUB-1|               
   |                |Map=L-NAT-PUB-1 |               
   |                |Rel=STUN-PUB-2  |               
   |                |                |               
   |(4) Alloc Resp  |                |               
   |<---------------|                |               
   |Src=STUN-PUB-1  |                |               
   |Dest=L-PRIV-1   |                |               
   |Map=L-NAT-PUB-1 |                |               
   |Rel=STUN-PUB-2  |                |               
   |                |                |               

If we added another NAT on that path, the number of messages
on the network does not double.  The number of messages on 
the network stays the same -- the messages merely have their
IP and UDP headers rewritten by the NATs.  That NAT function
does not increase the number of messages on the network.



Similarly, another message shown in that same figure is also
one message; however, it's shown as two messages:

L               NAT             STUN              NAT               R
                                Server
|(9) SIP INVITE  |                |                |                |
|------------------------------------------------->|                |
|                |                |                |(10) SIP INVITE |
|                |                |                |--------------->|

As you know, there aren't two messages -- it's one message that is
NATted.

If message 9 and 10 were shown as clearly as messages 1-4, messages
9-10 would be shown as four messages (one from L to its NAT, another 
from NAT to NAT, and the forth (shown) from NAT to R).  But this is
just one SIP message, which is NATted.  It is inaccurate  to count
it as two separate messages or as four separate messages, because
it is only one packet that is NATted.  Counting a STUN packet,
or a DNS packet, as a separate message each time it traverses a 
NAT is similarly inaccurate.

By my count, figure 22 exchanges 24 STUN/ICE messages and 6 
SIP messages.

> What happens if the two endpoints are in different ISPs that 
> have NAT of their own in addition to the ones in Fig. 22?

The same 24 STUN/ICE messages would be exchanged, and the same
6 SIP messages would be exchanged.

> What happens if one would try ICE along a P2PSIP route with 
> say 5-8 hops?

The SIP signaling messages would traverse those 5-8 additional 
hops between the P2PSIP nodes participating in the SIP proxy
overlay.  The STUN/ICE messages are sent peer-to-peer, and 
would remain the same 24 messages if you're doing the same 
Figure 22 flow.  

> Would there be hundreds of messages?

No.

-d


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to