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

Reply via email to