On Wed, 2007-07-18 at 21:19 -0400, Philip Matthews wrote:
> On 18-Jul-07, at 15:31 , Henry Sinnreich wrote:
>
> > Phil,
> >
> >> In my view, ICE _is_ a "Hole Punching Technique".
> >
> > Yes, you absolutely right, though the devil is in the details.
> >
> > We cannot go here into a shoot-out between hole punching or other
> > mentioned on the list vs. ICE, but there seems to be a huge difference
> > in effectiveness and performance.
>
> What precise algorithm are you talking about when you say this?
Well, here's the algorithm I use with my UA (the most recent versions I
might add):
STUN
UA Registrar Server
| REGISTER | |
|-5060------->| |
| w/rport | |
| | |
| 200 OK | |
|<5060--------| |
| | |
| | |
| STUN BReq | |
|-5060--------------------->|
| STUN BReq | |
|-5004--------------------->|
| STUN BResp | |
|<5060----------------------|
| STUN BResp | |
|<5004----------------------|
| | |
| . | |
| . | |
| 10sec | |
| . | |
| . | |
| | |
| STUN BReq | |
|-5060--------------------->|
| STUN BResp | |
|<5060----------------------|
| STUN BReq | |
|-5004--------------------->|
| STUN BResp | |
|<5004----------------------|
| | |
| | |
I pick up the rport addressing during the REGISTER transaction because
of the way my multithreading is done and because its nice to see the
same value coming from two different sources out on the Internet. The
port numbers on the UA are local port numbers. STUN BReq is a STUN
binding request and STUN BResp is a STUN binding response. Port 5004 is
for a single RTP session but the same algorithm is usable for any and
all UDP ports you need, e.g. additional session ports and RTCP. The
difference in order in the first and second sequence is intentional, the
implementation doesn't care when the responses show up.
This algorithm lets the UA know what its "visible" IP address and port
is all the time (assuming that rport and STUN are working) and keeps it
the same assuming that the NAT doesn't change it unilaterally (which I
have yet to see BTW). When signaling occurs, the "visible" IP address
and port are used in the Contact headers for SIP and in the SDP for
offers/answers for RTP.
Its just about as simple as it gets and I know you're going to say that
it doesn't work 100% of the time. I haven't measured how well its done
in deployments I've done as yet. I guess I need to do something along
those lines. The good news is, I haven't had anyone complain about it
so I guess I've been lucky. So let me have it... ;)
Thanks,
FM
_______________________________________________
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
