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 ("<sip:[EMAIL PROTECTED]>")
        , self.ss.siptag_from_str, ctypes.c_char_p ("<sip:[EMAIL PROTECTED]>")
        , self.ss.siptag_contact_str, ctypes.c_char_p ("<sip:[EMAIL 
PROTECTED]>")
        , 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.000000000 +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 @@
     name2 = "sips";
 
   if (!contact1 /* && !contact2 */) {
+#if HAVE_SOFIA_STUN
+    if (!stun_is_requested(TAG_NEXT(nua->nua_args)))
+    {
+#endif
+    /* XXX: mph: i found no way to use the 'stun' tports in favour to the
+                 local ones, therefore i add the local tports *ONLY* if stun
+                 is *not* requested or *not* available !
+    */
     if (nta_agent_add_tport(nua->nua_nta, NULL,
 			    TPTAG_IDENT("sip"),
 			    TPTAG_CERTIFICATE(certificate_dir),
@@ -1054,13 +1062,25 @@
 			    TAG_NEXT(nua->nua_args)) < 0)
       return -1;
 #if HAVE_SOFIA_STUN
-    if (stun_is_requested(TAG_NEXT(nua->nua_args)) &&
-	nta_agent_add_tport(nua->nua_nta, URL_STRING_MAKE("sip:0.0.0.0:*"),
+    }
+    else if (nta_agent_add_tport(nua->nua_nta,
+          /* XXX: use local ip/port instead of '0.0.0.0:*' to avoid binding
+                  to 127.0.0.1, which results in the error :
+                  tport_listen(0x816ad88): stun_bind()(pf=2 UDP/[127.0.0.1]:1165): Invalid argument
+
+                  the question remains how to obtain the local ip-address and
+                  port ?!?!
+          */
+          URL_STRING_MAKE("sip:192.168.0.6:5060"),
 			    TPTAG_IDENT("stun"),
 			    TPTAG_PUBLIC(tport_type_stun), /* use stun */
 			    TPTAG_CERTIFICATE(certificate_dir),
 			    TAG_NEXT(nua->nua_args)) < 0) {
       SU_DEBUG_0(("nua: error initializing STUN transport\n"));
+      /* XXX: mph: stun did not initialise, now we have no transports at all!
+                   can we live with this ? - or should we add local
+                   transports in this case ?!?!
+      */
     }
 #endif
   }
--- sofia-sip-1.12.6.orig/libsofia-sip-ua/nta/nta.c	2007-04-25 21:12:36.000000000 +0200
+++ sofia-sip-1.12.6/libsofia-sip-ua/nta/nta.c	2007-05-23 17:49:44.693019031 +0200
@@ -1934,6 +1934,51 @@
       str0cmp(via->v_port, v->v_port))
     clear = 1, v->v_port = via->v_port;
 
+  /* XXX: mph: use maddr as host in via header
+               shouldn't the maddr parameter be enough ? - however my
+               asterisk refuses to send the response to the address
+               specified in tha maddr parameter
+
+   rfc3261/18.2.2 Sending Responses
+
+   The server transport uses the value of the top Via header field in
+   order to determine where to send a response.  It MUST follow the
+   following process:
+
+      o  If the "sent-protocol" is a reliable transport protocol such as
+         TCP or SCTP, or TLS over those, the response MUST be sent using
+         the existing connection to the source of the original request
+         that created the transaction, if that connection is still open.
+         This requires the server transport to maintain an association
+         between server transactions and transport connections.  If that
+         connection is no longer open, the server SHOULD open a
+         connection to the IP address in the "received" parameter, if
+         present, using the port in the "sent-by" value, or the default
+         port for that transport, if no port is specified.  If that
+         connection attempt fails, the server SHOULD use the procedures
+         in [4] for servers in order to determine the IP address and
+         port to open the connection and send the response to.
+
+      o  Otherwise, if the Via header field value contains a "maddr"
+         parameter, the response MUST be forwarded to the address listed
+         there, using the port indicated in "sent-by", or port 5060 if
+         none is present.  If the address is a multicast address, the
+         response SHOULD be sent using the TTL indicated in the "ttl"
+         parameter, or with a TTL of 1 if that parameter is not present.
+  */
+
+  if (via->v_maddr)
+  {
+    SU_DEBUG_9 (("XXX %s: using via->v_maddr\n", __func__));
+    clear = 1, v->v_host = via->v_maddr;
+  }
+  else if (v->v_maddr)
+  {
+    SU_DEBUG_9 (("XXX %s: using v->v_maddr\n", __func__));
+    clear = 1, v->v_host = v->v_maddr;
+  }
+  SU_DEBUG_9 (("XXX %s: v->v_host = '%s'\n", __func__, v->v_host));
+
   if (clear)
     msg_fragment_clear(v->v_common);
 
@@ -2047,7 +2092,7 @@
 static void agent_update_tport(nta_agent_t *self, tport_t *tport)
 {
   /* Initialize local Vias first */
-  agent_init_via(self, tport_primaries(self->sa_tports), 0);
+  agent_init_via(self, tport_primaries(self->sa_tports), 1); /* XXX: mph */
 
   if (self->sa_update_tport) {
     self->sa_update_tport(self->sa_update_magic, self);
-------------------------------------------------------------------------
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