Hi Marcus and others,
On Tue, 29 May 2007, Marcus Priesch wrote:
>> it should work out of the box, but requires that server supports the rport
>> (RFC3581) extension.
>
> so the "Yes, the above API does not work at the moment. :(" comment from
> you in your previous mail wasn't meant for the rfc3581 part ?
no, that was specifically about using STUN binding discovery to generate
the contact/via for REGISTER (which is not standardized anywhere but still
implemented in many clients).
> unfortunately i haven't read the rfc before i was posting here :( -
> shame on me !
No, no problem. The fact that we have some code for STUN binding discovery
in our codebase proves that we haven't outright given up on the idea. It's
just that more recent stuff - like the IETF sip-outbound draft - is
looking much more promising to solve this specific issue.
> instead i got my info from a book over Voip - which was a bit unclear in
> this respect! furthermore packet analyzing ekiga's efforts also showed
> that when using nat, the IP address in the Via: header is actually the
> public address.
RFC3581 is just a much better way to solve this.
> the point why i came to this is caused by the fact that my asterisk
> (1.2.17) doesn't honour the "received" line correctly in the Via header.
>
> as far as i understand it:
> - asterisk should insert the received= header when the ip in the Via
> and the originating ip of the packet differ
> - asterisk should fill the rport= header with the actual port of the
> originating packet
> - asterisk should perform the actions required by this packet
> - when sending the answer back it should honor the received= and rport=
> headers if they are available ...
Yes, it should basicly send the packet back to the IP:port it received
the request from (for datagram transports). The problem with "fixing up"
Via/Contact with STUN is that you might discover the wrong IP (known
limitation of STUN/RFC3489).
For a good overview of state-of-art solutions to these issues can be found
in the following IETF document (work in progress):
http://tools.ietf.org/wg/sipping/draft-ietf-sipping-nat-scenarios/
> interestingly it simply sends the response back to 192.168.0.6 - which
> isn't reachable because its natted ;). in the sip.conf i have enabled
> rfc3581 for nat (also sip show users, sip show defaults show me this).
Hmm, sounds like a bug...
> only if i tell asterisk that my client is fully natted (nat=yes) it
> sends the response back to my nat firewall (but in this case, the doc
> says its now ignoring any settings found in SIP/SDP and blindly sends
> back to the sender - that was the reason why i thought the outgoing
> REGISTER message was buggy - and the fact that ekiga's (natted) REGISTER
> also looks different - and works !).
Yes, this is what should happen.
> i think that setting nat=yes in asterisk so that it ignores rfc3581 and
> received= headers is not the way to test this ... what do you use as a
> "reference registrar" ?!?!
I'm using some proprietary servers for testing, but for instance
SER/OpenSER does the right thing with Sofia-SIP's REGISTERs. Freeswitch
should work as well, but that's kind of expected (check the SIP stack that
is used). ;) Maybe I should try with a recent Asterisk as well.
>> new sockets. It would seem the current code does not do this, which
>> suggests major refactoring is needed.
>
> the problem is that when it binds to 127.0.0.1 it fails and doesn't try
> to bind to e.g. 192.168.0.6 (the "real" ip-address) ... and this is a
> major problem when the nua wants to initialise the STUN transport - so i
> think this is currently broken ... although not needed by anyone ;)
Yeah, this should still be fixed. Even though RFC3581 is a better (and
using TCP instead of UDP is even better!) solution, in some special
networks fixing Via+Contact with STUN still makes sense, so it wouldn't
hurt to support it.
> hmmm ... maybe some clarification on the use of STUNTAG_SERVER and
> NUTAG_OUTBOUND tags - from the users point of view would be helpful ;)
... yes, NUTAG_OUTBOUND()'s documentation was improved quite a bit
recently, but there's still room for improvement. Maybe we should add a
link to this thread to STUNTAG_SERVER's documentation. ;)
--
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
