Subject: [Fwd: [Sip] STUN state machine question]

From: "Frank W. Miller" <[email-masked]>
Date: Sun, 28 Aug 2005 23:40:22 -0400

Hi,

I didn't get any response to this message a week ago so I thought I
would try again...

Thanks for any comments...

FM

Subject: [Sip] STUN state machine question
From: "Frank W. Miller" <[email-masked]>
To: [email-masked]
Date: Sun, 21 Aug 2005 14:41:17 -0400
List-Id: Session Initiation Protocol <sip.ietf.org>

Greetings,

I've been working with STUN a bit lately and have run into an
interesting situation.  This may have been discussed elsewhere and I
just haven't seen it.  If so, I apologize and would appreciate a pointer
to that discussion.

In the state diagram, Figure 2 of RFC 3489, there is a path to repeat
Test I.  That is, if the first execution of Test I yields a different IP
address than the current host interface IP address and no response is
received from the STUN server for Test II, the client repeats Test I
sending the Binding Request to the IP address specified in the
CHANGED-ADDRESS attribute from the first execution of Test I.

My question is, what should the client assume if no response is received
for the repeated execution of Test I?

It seems to me that in theory, this situation should never occur.  The
reason is because the first execution of Test I returned a response and
the second execution is doing the same thing, just with a different IP
address and port number.  However, I have encountered situations in
practice where this does occur.

My guess would be that you can certainly assume a NAT and use the
MAPPED-ADDRESS that you get from the response to the first Test I.
Would that be a good assumption?  Also, what type of NAT would I then
call that?

Thoughts?
FM

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 29 Aug 2005 17:24:02 -0700

CC'ing the BEHAVE mailing list, where much of this activity is discussed
now-a-days.  The revision to RFC3489 (STUN) is also owned by BEHAVE
(draft-ietf-behave-rfc3489bis).

Determining the 'type of NAT' has been found to less useful than originally
envisioned.  Some NATs change their behavior after they've exchanged packets
for a little while with a stream, and some NATs change behavior when they're
really busy and become symmetric.  So testing a NAT and declaring it's a
certain kind of NAT may result in different answers based on the NAT's load,
the duration of the stream being used for the test, and other factors.

-d

-----

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Frank W. Miller
> Sent: Sunday, August 28, 2005 8:40 PM
> To: [email-masked]
> Subject: [Fwd: [Sip] STUN state machine question]
> 
> 
> Hi,
> 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Frank
W. Miller
Sent: Sunday, August 21, 2005 11:41 AM
To: [email-masked]
Subject: [Sip] STUN state machine question

Greetings,

Thoughts?
FM