Hi Kai, dear list,
thanks for your reply, i think i have tackled down the problem. it was
caused by some confusion i encountered during reading some books over
Voip and experimenting with asterisk, sofia-sip and ekiga - yeah, read
the fine rfc and you should be happy - i read it - and now i'm feeling
even happier ;)
On Sat, 2007-05-26 at 13:43 +0300, Kai Vehmanen wrote:
> 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.
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 ?
unfortunately i haven't read the rfc before i was posting here :( -
shame on me !
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.
and this is what i wanted sofia-sip to do - and expected from my
attempts - and what my patch actually does ;)
... but which definitely is not whats actually defined in rfc3581 - so
you are right sofia-sip is correct (not only!) in this concern !!! and i
apologise for the trouble i have created !
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 ...
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).
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 !).
so the question remains: is asterisk buggy in this case ? - i doubt
that ! - i googled around but was not able to find anything except a bug
which was fixed in 1.2.9 regarding rfc3581 ... so is anyone on the list
experiencing the same behaviour ?
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" ?!?!
> > 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".
once again: mea culpa ;)
> > 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.
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 ;)
> 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.
i am with you with that, but i thought it should write its public ip in
the Via header (as stated above), instead of its local ip - and thats
where you would need stun to discover it ...
> 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.
yes, ack !
> 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.
yup
> ... 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. :)
hmmm ... maybe some clarification on the use of STUNTAG_SERVER and
NUTAG_OUTBOUND tags - from the users point of view would be helpful ;)
thanks a lot,
marcus.
-------------------------------------------------------------------------
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
