RE: [reSIProcate] Fwd: [reSIProcate-commit] COMMIT: resiprocate 6128moetje: Added STUN client support

["Matthias Moetje - TERASENS GmbH" <moetje@xxxxxxxxxxxx>]

Bruce,

thanks a lot for your comments.

I agree that we should make efforts to make reSIProcate
handle ICE. When your student is ready to contribute
the new basic STUN features we might rediscuss in which way
this is implemented best (through an interface on the
transport or rather with messages sent through the
stack and dum).

The next thing on my list is support for UPnP, though..


Freundliche Grüße,

Matthias Moetje
______________________________________________

TERASENS GmbH       Phone:  +49.89.143370-0
Augustenstraße 24   Fax:    +49.89.143370-22
80333 Munich        e-mail: info@xxxxxxxxxxxx
GERMANY             Web:    www.terasens.com
______________________________________________ 

> -----Original Message-----
> From: lowekamp@xxxxxxxxx [mailto:lowekamp@xxxxxxxxx] On 
> Behalf Of Bruce Lowekamp
> Sent: Friday, April 14, 2006 5:01 PM
> To: Matthias Moetje - TERASENS GmbH
> Cc: jason@xxxxxxxxxxxxxxx; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] Fwd: [reSIProcate-commit] COMMIT: 
> resiprocate 6128moetje: Added STUN client support
> 
> Matthias,
> 
> I completely agree that your code solves 95% of NAT situations, i.e.
> where you have a node behind an independent mapping NAT and 
> all communication goes to nodes on the other side of that 
> NAT.  As long as the application never lets the NAT mapping 
> expire, that problem is completely solved.
> 
> My concern is directed more at trying to find a solution for 
> the other 5% of the problems and to make sure the solution 
> preserves compatibility with a few of the newer protocols 
> being developed (at least at the level of making sure 
> implementing them doesn't become harder).
> 
> On 4/13/06, Matthias Moetje - TERASENS GmbH 
> <moetje@xxxxxxxxxxxx> wrote:
> >
> >
> > > There's a general issue, though, that this interface only 
> supports a 
> > > single outstanding stun request, which really isn't going to be 
> > > sufficient for more complicated UAC/UAS code.
> >
> >
> > I'm not quite sure what kind of  "complicated UAC/UAS" 
> scenanrios you 
> > are refering to. The STUN information is always specific to 
> each UDP 
> > transport, i.e. each UDP transport has exactly one public mapped ip 
> > address and port no matter how complicated the UAS/UAS 
> scenarios are 
> > that use the transport. (At least if we are talking about 
> current STUN 
> > implementations that can't deal with symmetric NATs)
> 
> Unfortunately, there's a lot of ground between an address and 
> port independent mapping NAT and a full symmetric NAT. 
> draft-ietf-behave-nat-udp-05 discusses a lot of examples of 
> bizarre behavior that NATs can produce.  Two of the big 
> issues have apparently been large commercial NATs and NATs 
> that change their mapping behavior as they get more heavily loaded.
> 
> 
> > - all requests are identical (sent to the same STUN server)
> >
> > - several requests may be sent that set the flag to false, but
> >   as soon as requests are received the flag will be set to true
> >   and as soon as the flag is true the application does not send
> >   any more tests. (for a certain interval at least)
> 
> again, for the simple example, this works.  For the more 
> complex network setups, it fails.  Actually, the certain 
> interval probably means there needs to be some way to result 
> the result flag already.
> 
> >
> >
> >
> > > - Primarily, have you taken a look at rfc3489bis-03 or 
> recent drafts?
> > > The usage has changed a bit.  I have a student who's working on 
> > > implementing the new version, and we hope to be able to 
> contribute 
> > > that in the near future.
> >
> >
> > I haven't had a look at this yet. My focus is on making 
> this work with 
> > current implementations.
> >
> >
> > > - One of the key behaviors needed is the ability to issue 
> a binding 
> > > query/connectivity check to any arbitrary destination, 
> and in fact 
> > > there may be multiple outstanding queries.  This implies that the 
> > > stun request needs to probably return a handle or require a 
> > > conventional event handler so that replies can invoke the handler 
> > > with a handle to match the specific stun request.
> >
> >
> > OK, this is nice, but this is incompatible with current SIP 
> implemenations.
> > You can't rely on the other party being able to respond to STUN 
> > requests on their SIP ports. Even in reSIProcate this is 
> disabled by 
> > default. So I think for the near future we will continue to 
> rely on an external STUN server.
> 
> I'm not trying to suggest that we do anything that would 
> break the single-external-stun-server model, but since it's 
> well-established that there are a lot of shortcomings with 
> that model and since several new proposals are evolving that 
> address these shortcomings, I think it would be best if 
> resiprocate tries to support them somewhat.
> 
> 
> >
> >
> > > We should make sure that whatever the design is, it provides the 
> > > services necessary to higher layers can implement ICE on top of 
> > > this.
> >
> >
> > Please correct me if I'm wrong, I just had a brief look 
> over the ICE 
> > concept, but as far as I understand it so far I'd say: 
> Everything that 
> > ICE adds to STUN (and that is mainly the ability to 
> traverse symmetric 
> > NATs) would need to be implemented in the media/RTP stack, 
> not at the SIP layer.
> >
> > For symmetric NAT traversal on the SIP layer I see the following two
> > concepts:
> >
> > - A UAS or UAC just replies to the IP address/port where it
> >   received the packet from and ignores via/contact
> >   (I think this is mentioned in the ICE specs?)
> >
> > - STUN communication is done with the remote party directly
> >   over the actual SIP ports instead of an external STUN server
> >
> 
> I believe ICE requires STUN support from both the peers and 
> an external STUN server.  I think it's a bit of an 
> oversimplification to say that it adds support for symmetric 
> NATs.  It adds supports for a lot of more complicated 
> scenarios (contacting nodes both inside and outside the NAT, 
> for example).
> 
> You're right that it's a lot more complex since it requires 
> interaction between the RTP/RTCP and the SIP connection.  I 
> don't think I fully understand the requirements yet, either.
> 
> >
> >
> > > I like the ability to create a StunMessage the same way a
> >
> > > SipMessage is created for something like Register, which allows 
> > > either a simple call to create the standard STUN messages, but a 
> > > more advanced use can be made by manipulating the StunMessage 
> > > directly.
> >
> >
> > Personally I'd prefer a UdpTransport that performs all STUN 
> > functionality automatically :-)
> >
> 
> Yeah, I don't think this should be the only way to do it, but 
> for applications that need to have more control, a 
> higher-level interface would be useful.
> 
> Bruce
>