< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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


Bruce,
 
thanks very much for looking into this.
 
> Actually, I don't understand what the lock is doing here. 
 
The lock is there to protect the mStunSuccess variable from being modified by another thread during execution of one of the three functions (process, stunSendTest, stunResult).
In fact it does not seem necessary to lock the mutex right at beginning of the Process function (I put it there before I noticed that the txFiFo is protected by a mutex anyway). I will move it behind the if statement that detects a STUN response so that it only gets locked when a STUN response is atually received. So we can turn down at least this concern :-)
 
> 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)
Actually for me the ideal solution would be a userprofile flag that tells the stack to use a detected public mapped tuple for sending. All of the STUN detection stuff could be done by the transport then. I see no benefit in letting the application deal with STUN message sending and let these messages travel all the way through the stack. (The way this needs to be implemented should be quite standard and not application specific.)
 
 
> So if there's a lock, it actually needs to be in place to prevent a
> second call to stunSendTest from returning until stunResult has
> completed successfully.  But I'm pretty sure we don't want to do
> that, either.
 
Of course not because we never know if we will get a response or if the packet will get lost. When you look at the current way I'm using the STUN functions from my application (please see wiki) you will see that there is no problem that there is only a single request. Because
 
- 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)
 

> - 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.

> 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 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 :-)
 
> There's also an interesting question of whether we would want to
> implement KeepAlive messages using the same interface.
 
The current implementation can easily be used to keepalive a current NAT mapping, just call stunSendTest regularly.

Apart from these long-/mid-term considerations my main focus is making STUN work with reSIProcate in the same way that most of devices/applications already do these days. The current implementation surely was a low-effort solution - it took only a few hours - but it is stable and works well. Though there are still some issues that need to be solved quickly:

- the setOverrideHostAndPort setting is honored when a new message is created but not in subsequent message (e.g. Ack)

- when i modify the via to the mapped ip and port I also need to setFixedTransport..., otherwise the message will fail ("no matching transport"). But when I use this, the port in the via is overwritten again with the local port while the public IP remains in the via

Maybe someone who knows the stack better than I has an idea why this is happening?`

Of course it would be best if the application just does setOverrideHostAndPort and everything is done automatically (also set via). Are there any concerns implementing it this way?

Best regards,

Matthias