Hi, On Tue, 22 May 2007, Marcus Priesch wrote:
> thanks for the reply, sad enough to hear that stun doesn't work for the > signalling :( but hey, nobody is perfect ;) - so, whats the way to go > then ? - how do i manage to get the rport stuff working correctly ... do > i need to do some manual tuning, or should it work out-of-the-box ? the it should work out of the box, but requires that server supports the rport (RFC3581) extension. > webpage says that "symmetric response routing" is supported ... Yes, that refers to RFC3581 - "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing". > and i get another transport determined by stun module - i think this > should be fixed in nta_agent_add_tport (i think when it wants to bind > the server ?!? - it should not try the 127.0.0.1 transport - in general: > for what reason do you bind to 127.0.0.1 actually ? who needs it ?) No need. Now I'm not personally familiar with this code, but in my view it should perform a STUN query from all bound UDP sockets, and not create any new sockets. It would seem the current code does not do this, which suggests major refactoring is needed. But then I'm still unsure why anyone really needs STUN for signaling? I personally think it's a very dangerous idea, because with NATs that do endpoint dependent mapping (allocate the public side IP:port based on destination), STUN would discover an invalid public contact (the mappings will be different for STUN and SIP servers). This is bad as the registration is succesful, but in reality it can be that nobody can make calls or send messages towards to you. And as a client you have no way to figure out that this is the case. This is very, very, very bad. Use of rport/3581 is much safer as the discovery is done against the same destination as the actual REGISTER message is sent to. Thus this discovery works even if you have a endpoint-dependend-mapping NAT. In short, STUN for signaling is only useful in controlled SIP services, where both the SIP servers and access networks (NATs) are provider controlled. If you have this much control, you might just as well configure your service to enable rport/3501. ... of course, if someone can prove me wrong, I'm willing to change my mind and consider a serious look at the STUN code in nua/nta. :) -- links, my public keys, etc at http://eca.cx/kv ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
