[Serusers] Problem : Can SER process the reINVITE messages pr operly?

[Ricardo Martinez]

Hello Greger and SER users.
	About this issue here are some test that i made.  I added the
lookup("location") as you recommend me : 

        # -----------------------------------------------------------------
        # Loose Route Section
        # -----------------------------------------------------------------
        if (loose_route()) {

                if (has_totag() && (method=="INVITE" || method=="ACK")) {
                        lookup("location");
                        if (isflagset(6) || client_nat_test("3") ||
search("^Route:.*;nat=yes")){
                                setflag(6);
                                use_media_proxy();
                        };
                };

                route(1);
                break;
        };


Unfortunately, i'm still unable to have voice in both ways, but this
modification seems to handle better the reINVITE message.  And this is why.
For the normal approach (i mean the initial onsip_pstn configuration) the
second INVITE was not using the mediaproxym as Greger pointed.  Now, as you
can see in the debugs that i'm attaching, the second invite is using the
mediaproxy, and therefore the "c" parameter in the SDP message is being
correctly modified by SER.  So, i don't understand why this time the call is
failing. Could it be that mediaproxy is not capable to handle the
reINVITEs?.  For example in the debug from mediaproxy (i'm also attaching
this one), i see a warning message like this : warning: Received packet from
a third party: 200.0.0.7:16432.  It seems like mediaproxy is not accepting
"voice packets" from the second IP (the one indicated by the reINVITE).
Why? 
Also, when the call is established this is the output from the "session"
command : 

Caller                Via                   Called               Status
Duration  Codec  Type   Traffic        
----------------------------------------------------------------------------
--------------------------------------
200.0.0.6:17480 - 200.0.0.5:35094 - 200.0.0.4:46115  inactive     0'24"
G729   Audio  0/16.75k/16.75k

The call is established but between the first IP (Asterisk box) and the
endpoint public IP.
So, could this be a problem with mediaproxy?.  I read the changelog from the
version 1.3.1 and this is what i found : 

Changes from version 1.2.1 to 1.3.0
-----------------------------------

- Only create a new session if a request belongs to the first INVITE
  (no longer creates new sessions on re-INVITEs)

could it be related?.

I also have a general question about the reINVITE.  As you can see the first
INVITE has in his URI the domain name for the number :
5555848114 at sipvoiss.desarrollo.redvoiss.net (Frame 1 from the debug).  The
reINVITE sent by Asterisk has the URI : 5555848114 at 200.0.0.4.  Is this ok?,
despite of this the reINVITE is correctly redirected to the endpoint.  (You
can check this in the frame 13  from the debug).

Thanks again.

Regards,

Ricardo Martinez.-


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: reINVITE_mediaproxy_debug.txt
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050727/6f6066e2/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: reINVITE_debug_problem_2.txt
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050727/6f6066e2/attachment-0001.txt>