Dan, What you say makes sense but there is a lingering suspicion that after admitting that RFC 3489 (STUN), RFC 4091, 4092 (ANAT), etc. just don't work is that such paper evaluations are in no way a replacement for proof and measurements. We still need an explanation why the right approach cannot be taken:
* Publish open source code at Sourceforge.net or similar, * Publish a test tool as well, * Gather and publish the results, possibly involving SIPit or another, * Perfect the OS code and the protocol until it works OK. This has been done for "Hole Punching for P2P" in http://www.brynosaurus.com/pub/net/p2pnat/ What if ICE proves to be no better than its predecessors? So how can one compare something that has tools, measured and published results with something like ICE that we have to take on pure faith? My assumption is that hole punching is much more effective for P2PSIP and I have copied the P2PSIP WG on this. The ratio of messages is probably 5:1 or higher for ICE vs. hole punching and this is critical when routing a P2PSIP message over an overlay in 5-10 hops. Of course I cannot prove it since as yet ICE cannot be measured. Let's do ICE the right way, there is too much at stake here. Henry -----Original Message----- From: Dan Wing [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 1:19 PM To: Henry Sinnreich; 'Magnus Westerlund' Cc: [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [BEHAVE] Re: ICE deployment data before LC for RFC > 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
