Re: [Sofia-sip-devel] working stun - symmetric response routing anyone ?
Hi,
On Wed, 16 May 2007, Marcus Priesch wrote:
> first of all, thanks for that great piece of software, i am using it now
> for quite a while and it's really nice ;) - under python via ctypes -
> YEAH !
thanks, that's good to hear! :)
> but i im totally stuck with the stun thing - even the sofsip-cli isn't
> working as expected.
>
> i have searched the mailing list, looked at code which is using
> sofia-sip (sofsip-cli, tapioca and freeswitch) but no success.
>
> using the stun module standalone works perfect ! - even in python ;)
Yes, this is a known issue I'm afraid. STUN is not currently enabled for
signaling (i.e. for updating the "Contact" for registrations). It _is_
usable for a SIP client wishing to use sofia-sip's STUN module to discover
IP addresses for media (i.e. to SDP).
This has not been an urgent item for us at least, as use of "rport"
(RFC3581) gets you basicly the same results (for SIP signaling). And in
the future, the 'SIP outbound' extension will completely remove the need
for clients to guess their public Contact bindings. There are however many
people interested in this, so patches are very much welcome.
>self.ss.nua_register \
>( self.register_h
>, self.ss.nutag_registrar, ctypes.c_char_p ("my.own.regist.rar")
>, self.ss.stuntag_server, ctypes.c_char_p ("stun.voipbuster.com")
>, self.ss.nutag_outbound, ctypes.c_char_p ("natify")
>, self.ss.nutag_outbound, ctypes.c_char_p ("use-rport")
>, None, None
>)
Yes, the above API does not work at the moment. :(
Lot of the code is there already, but someone just has to finish the work
in order to make it really work.
> stun_handle_init: entering.
> stun_handle_init("stun.voipbuster.com"): called
> stun_atoaddr: entering.
> stun_bind: entering.
> stun_discovery_create: entering.
> assign_socket: entering.
> stun_request_create: entering.
> stun_make_binding_req: entering.
> stun_send_binding_request: entering.
> stun_send_message: message sent to 194.221.62.209:3478
Hmm, this goes further than I remembered.
> tport_listen(0x816c5a8): stun_bind()(pf=2 UDP/[127.0.0.1]:32861): Invalid
> argument
Ugh, this looks like a bug. Hmm patches are welcome! :)
> read something on the list that 1.12.3 had problems with stun, and
> 1.12.2 was fine ... but the same there ... hmmm.
Yes, this applied to the STUN module itself, but 1.12.6 and the current
devel tree should be fine (you can test with the 'stunc' test tool).
--
under work: Sofia-SIP at http://sofia-sip.sf.net
-
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
Re: [Sofia-sip-devel] working stun - symmetric response routing anyone ?
Hi Kai, 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 webpage says that "symmetric response routing" is supported ... well, anyway, i digged a little bit deeper in the code (1.12.4 was it actually) and found out the following: in nua_register.c line 1033 (call to nta_agent_add_tport in function nua_stack_init_transport), if i dont bind to 0.0.0.0 but instead bind to my real address (192.168.0.6), the following message disappears: > > tport_listen(0x816c5a8): stun_bind()(pf=2 UDP/[127.0.0.1]:32861): Invalid > > argument > > Ugh, this looks like a bug. Hmm patches are welcome! :) 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 ?) if in nua.c line 1954 (agent_init_via in function agent_update_port) i change the 0 to 1 (do_maddr) then i also get the "maddr" attribute for that transport with the correct public address determined by stun ;) however, the register message get sent with my local address (192.168.0.6) in the contact header. so my strategy would be the following: - use only the "stun" transport if there is one for all messages q: is there a possibility to force the use of one transport ? - or is it possible to remove all the transports (192.168.0.6/127.0.0.1/tcp/udp) except the stun transport ? - handle the "maddr" attribute (correctly ?) - should it be in the Contact header as ip-address ? - debug the rport and received stuff ... as i read in some VoIP book, when NAT is detected - via mismatch of received header and own IP, the register should be re-done with the ip-address from the "received" header ... i saw this behavior when the stack uses the ".is.invalid." Contact address ... hmmm ?!?! either way, can you give me some hints on how to finish the work based on the code that existing ... or which way seems to be the way to go ?!? this would be very helpful. i would really much like to contribute the code to get the stun stuff up and running as i personally also need it. but i would like to rather do it the right way, than to hack something thats working but it fixes in the wrong places ... ;) should i go on with 1.12.6 or should i go with the devel-repository ? > Yes, this applied to the STUN module itself, but 1.12.6 and the current > devel tree should be fine (you can test with the 'stunc' test tool). thats working for me - at least with the stun.voipbuster.com, stunserver.org doesnt send me any responses back ... thanks, mexx. - 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
Re: [Sofia-sip-devel] working stun - symmetric response routing anyone ?
Hey Marcus, Great to hear that you created the python bindings! Could you send the code for me? I'd be happy to try that out and maybe we could consider either merging that to our tree or to create another public project for them? All the best, Martti On 5/16/07 6:42 PM, "ext Marcus Priesch" <[EMAIL PROTECTED]> wrote: > Dear All, > > first of all, thanks for that great piece of software, i am using it now > for quite a while and it's really nice ;) - under python via ctypes - > YEAH ! - 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
Re: [Sofia-sip-devel] working stun - symmetric response routing anyone ?
Hi Martti, ... wouldn't call them "bindings" :) its rather a couple of automatically generated (with the ctypes code generator) python files from some of sofia-sip's .h files (nua, soa, stun, su_wait) and a couple of receipts on how to specify the tags, how to create the callback functions and how to access the sofia-sip data. the rest (the real thing (tm)) is our telephone framework which i am not sure will ever be released as open-source - not that *i* dont want it, but i'm not sure if i can convince my boss to do so ... ;) and ... most of all ... what to do with the best python bindings without working stun support :( any hints ?!?! ... i am totally stuck - have tried all that comes to mind - but with no success at all - i am pretty sure the "big picture" of the sofia-sip internals is missing at all ... so any help would be very welcome on where and how to look around and start fixing it ... greets, mexx. On Tue, 2007-05-22 at 18:47 +0300, Martti Mela wrote: > Hey Marcus, > > Great to hear that you created the python bindings! Could you send the code > for me? I'd be happy to try that out and maybe we could consider either > merging that to our tree or to create another public project for them? > > All the best, > > Martti > > > On 5/16/07 6:42 PM, "ext Marcus Priesch" <[EMAIL PROTECTED]> wrote: > > > Dear All, > > > > first of all, thanks for that great piece of software, i am using it now > > for quite a while and it's really nice ;) - under python via ctypes - > > YEAH ! > > > > - > 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 > - 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
Re: [Sofia-sip-devel] working stun - symmetric response routing anyone ?
Hi there,
well i came up with some modifications to the code without further
understanding of the sofia-sip internals ... ;) - kai, martti, pekka,
where is the big picture - i'm pretty sure there is one ... ?!?!
however, only one thing is missing, but with the hardcoded ip-address
it works for me ;).
i'm sorry for this hack, but without support from the insiders i will
have to dig around even more, until i can fix this correctly - there
are far tooo many open questions ...
a brief description of what it actually does:
you need:
self.nua = self.ss.nua_create \
( self.su_root# root object (reactor)
, self.sip_event_callback_p # function pointer to callback
, None# nua_magic
, self.ss.stuntag_server, ctypes.c_char_p ("stun.voipbuster.com")
, self.ss.tptag_public, 2 # i'm not sure if this is needed
, self.ss.tptag_log, 1# not really but it makes sense ;)
, None, None
)
self.ss.nua_set_params \
( self.nua
, self.ss.nutag_registrar, ctypes.c_char_p ("my.reg.is.trar")
, None, None
)
self.register_h = self.ss.nua_handle \
( self.nua, None
, self.ss.nutag_url, ctypes.c_char_p ("sip:my.reg.is.trar")
, self.ss.siptag_to_str, ctypes.c_char_p ("")
, self.ss.siptag_from_str, ctypes.c_char_p ("")
, self.ss.siptag_contact_str, ctypes.c_char_p ("")
, None, None
)
self.ss.nua_register \
( self.register_h
, self.ss.nutag_registrar, ctypes.c_char_p ("my.reg.is.trar")
None, None
)
i am not sure if all those redundant tags are needed, but thats at least
the same order sofsip-cli does it ...
what the patch does:
nua_register.c:
- in nua_stack_init_transport we only bind to the stun tport if stun is
available - otherwise the non-public transports are used by default.
i found no way to change this behaviour, nor the location where this
takes place.
- instead of binding the "stun" transport to "0.0.0.0:*" we must bind
it to the local address, and the port we want, otherwise the stack
tries to bind it to 127.0.0.1:* and fails - i havent found the place
where this happens either - maybe this should be fixed somehow in
tport_listen, but i dont know how.
- the huge problem is where to get the local ip-address, and most of
all: where to get the port number, as this is what the application
provides! so any hint on this would be - as always - very welcome :)
- if the nta_agent_add_tport fails for stun - the whole stack fails to
initialise with an assertion, as no tports are available then. maybe
we should add the local tports then ... ?!?!
nta.c:
- in outgoing_insert_via i use the determined 'maddr' parameter as the
'host' value for the Via: header. although it is specified in the rfc
that the presence of the 'maddr' parameter should be sufficient, my
asterisk refused to send the answer to my natted address. ekiga also
sets the host part to the natted address, and afaik its meant this
way - or am i wrong here ?
- in agent_update_tport i have enabled the 'use_maddr' flag, as
otherwise the stun discovery doesnt take place. at least i think this
was the reason ... its some days ago i figured this out ;)
well, i am pretty sure that this is a very ugly hack, and i am not very
comfortable with posting it here - but i think it is absolutely
necessary to get on with this ... furthermore i am a little bit in a
hurry - i have to have stun working by the end of next week and i trusted
whats stated on the features homepage ... :( ... and sdp/rtp is also
waiting for me ...
so please give me your feedbacks ... especially on where to get the
local ip-address from ... and a how i can specify the port ... but i'm
sure i can go with a random port here also ... or with fixed 5060 for
the time beeing ... and dont forget some hints on how to fix it
correctly ;)
thanks for all & cheers,
mexx.
ps: according the python bindings ... what Mikhail wrote:
thats why i wouldnt call them 'bindings' :)
the ctypes and python combo was meant as a way to experiment with
the sofia-sip stack in a scripting environment - which turned out
to be very nice ;) - further on, it was a funny way to write the
entire application in python instead of c - which saved us a lot
of time ;) - and runs also very nice on our embedded target ;)))
but im pretty fine on thinking about a some more pythonic approach
on creating a nice sofia-sip binding ... but for twisted i have
in mind that there is already some sip stack existing ... but it
was tooo large to run on our embedded target ;)
--- sofia-sip-1.12.6.orig/libsofia-sip-ua/nua/nua_register.c 2007-04-25 21:12:37.0 +0200
+++ sofia-sip-1.12.6/libsofia-sip-ua/nua/nua_register.c 2007-05-23 18:25:37.439557284 +0200
@@ -1044,6 +1044,14 @@
Re: [Sofia-sip-devel] working stun - symmetric response routing anyone ?
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
Re: [Sofia-sip-devel] working stun - symmetric response routing anyone ?
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 dis
Re: [Sofia-sip-devel] working stun - symmetric response routing anyone ?
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
