[Serusers] Problem : Can SER process the reINVITE messages properly?
Greger V. Teigre
greger at teigre.com
Mon Aug 1 02:30:45 CEST 2005
BTW, I sketched out a few other solutions, where I believe at least a couple
should be valid attempts. Did you try those and what were the results?
g-)
Ricardo Martinez wrote:
> 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.-
>
>
>
>> -----Mensaje original-----
>> De: Greger V. Teigre [mailto:greger at teigre.com]
>> Enviado el: Miércoles, 20 de Julio de 2005 3:06
>> Para: Ricardo Martinez; serusers at lists.iptel.org
>> Asunto: Re: [Serusers] Problem : Can SER process the reINVITE
>> messages properly?
>>
>>
>> Hm. This was a tricky one. I would like to ask a second
>> opinion from you
>> NAT gurus on my musings below. What is the most appropriate
>> response to
>> Ricardo's scenario? WARNING to others: This is getting fairly
>> technical on
>> NAT/SDP... ;-)
>>
>> The reINVITE from Asterisk has a valid IP address and a valid
>> (but new) SDP
>> media ip (C=IN IP4 200.0.0.7). nat=yes is correctly not
>> present in the
>> reINVITE from Asterisk (it is not NATed). Thus
>> use_media_proxy is correctly
>> not used in the reINVITE, i.e. client_nat_test("3") and test
>> on nat=yes will
>> not trigger under the has_totag if statement (loose route
>> processing):
>>
>> if (loose_route()) {
>>
>> if (has_totag() && (method=="INVITE" || method=="ACK")) {
>>
>> if (client_nat_test("3") || search("^Route:.*;nat=yes")) {
>> setflag(6);
>> use_media_proxy();
>> };
>> };
>>
>> route(1);
>> break;
>> };
>>
>> In the OK from the Linksys:
>> U 200.0.0.5:5060 -> 200.0.0.6:5060
>> SIP/2.0 200 OK.
>> To:
>> <sip:5555848114 at sipvoiss.desarrollo.redvoiss.net>;tag=64d7492d
>> b018b13ai0. From: "5565625858196"
>> <sip:5565625858196 at sipvoiss.desarrollo.redvoiss.net>;tag=as5d352c9a.
>> Call-ID:
>> 0848ef78297116742562204e2c04cbcb at sipvoiss.desarrollo.redvoiss.net.
>> CSeq: 104 INVITE.
>> Via: SIP/2.0/UDP 200.0.0.6:5060;branch=z9hG4bK518d870e.
>> Record-Route: <sip:200.0.0.5;ftag=as5d352c9a;lr=on>.
>> Contact: 5555848114 <sip:5555848114 at 200.0.0.4:46081>.
>> Server: Linksys/PAP2-2.0.10(LSb).
>> Content-Length: 237.
>> Content-Type: application/sdp.
>> .
>> v=0.
>> o=- 33068 33068 IN IP4 192.168.15.200.
>> s=-.
>> c=IN IP4 192.168.15.200.
>> t=0 0.
>> m=audio 16424 RTP/AVP 18 100 101.
>> a=rtpmap:18 G729/8000.
>> a=rtpmap:100 NSE/8000.
>> a=rtpmap:101 telephone-event/8000.
>> a=fmtp:101 0-15.
>> a=ptime:30.
>> a=sendrecv.
>>
>> ...you have 192.168.15.200, a private c= address in SDP, but
>> the Contact has
>> correctly been fixed (200.0.0.4:46081). So it seems the OK is
>> processed
>> correctly in onreply even though it does not show up in the
>> debug. Flags 6
>> and 7 are not set, so use_media_proxy is correctly not run.
>> The problem is
>> that flag 6 should have been set (the Linksys is NATed), but
>> as the reINVITE
>> is not processed using lookup("location") the flag will not
>> be picked up
>> from usrloc.
>> ----------------------------------------
>>
>> However, now that Asterisk in the reINVITE is requesting
>> another (valid) IP
>> as media destination, the question is: what is propor behavior?
>>
>> The most natural would be to add a lookup("location") after:
>> if (has_totag() && (method=="INVITE" || method=="ACK"))
>> and then add isflagset(6) to the or test:
>> if (isflagset(6) || client_nat_test("3") ||
>> search("^Route:.*;nat=yes")) {
>> setflag(6);
>> use_media_proxy();
>> };
>>
>> However, I'm not sure the lookup will work, because the R-URI
>> is likely to
>> be the direct address (5555848114 at 200.0.0.4:46081) and not
>> the registered
>> URI (@domain.com). It would be tempting to try to see if we
>> somehow could
>> make nat=yes set in the early INVITE. We would have to split the
>> record_route section in two. One to handle !="REGISTER &&
>> !="INVITE" with a
>> regular record_route() and wait until AFTER
>> lookup("location") (maybe in
>> route[1], the default handler) to add the following:
>> if(method=="INVITE")){
>> if(isflagset(6)) {
>> # INSERT YOUR IP ADDRESS HERE
>> record_route_preset("192.0.2.13:5060;nat=yes");
>> } else {
>> record_route();
>> }
>> }
>>
>> This would make sure that not only dialogs where caller is
>> nated, but also
>> where callee is nated, will be tagged as nated. This again
>> would cause
>> nat=yes to be set and rtp proxy forced, further flag 6 is
>> set, and thus the
>> OK also processed with use_media_proxy().
>>
>> BUT: Would this nat=yes cause any problems in other
>> scenarios??? I'm not
>> sure, but I don't think so. If that is correct, this is
>> maybe the right
>> solution.
>> ---------------------------------------
>> OTHER (SIMPLER?) SOLUTIONS:
>> ----------
>> Instead you could add ||client_nat_test("1") together with
>> isflagset 6 and 7
>> in your reply route:
>> if ((isflagset(6) || isflagset(7) || client_nat_test("1")) &&
>> (status=~"(180)|(183)|2[0-9][0-9]"))
>>
>> but it will not work because the reINVITE did not get
>> use_media_proxy().
>>
>> Or, you could instead add fix_nated_sdp("2"); in your onreply route:
>> if (client_nat_test("1")) {
>> fix_nated_contact();
>> fix_nated_sdp("2");
>> };
>> WARNING! You will have to add else in between this test and
>> the previous to
>> avoid messing up use_media_proxy().
>>
>> This will fix the SDP (c=IN IP4), but it will probably not
>> help, because the
>> port is still unknown. You could use "3" instead in
>> fix_nated_sdp, this
>> will add direction=active to the OK. However, another thread
>> stated that
>> Asterisk does not support direction=active. If it does, it
>> will probably
>> work and you get a non-proxied stream between Asterisk and
>> the Linksys.
>>
>> Or finally, the third option would be to add the (hopefully)
>> fixed IP in the
>> loose_route test:
>> if (src_ip==200.0.0.6 || client_nat_test("3") ||
>> search("^Route:.*;nat=yes")) {
>> setflag(6);
>> use_media_proxy();
>> };
>>
>> This would cause the OK automatically to get use_media_proxy.
>>
>> Ricardo, could you please test these various solutions and
>> see if they
>> really work or if (where...) I go wrong :-)
>> g-)
>>
>> Ricardo Martinez wrote:
>>> Hello Greger.
>>> Thanks for your answer on this topic. Now i'm attaching more debug
>>> information (the /var/log/messages from mediaproxy, the ngrep output
>>> and some xlog statements in the ser.cfg file) beside some
>> comments in
>>> the file reINVITE_debug_problem.txt.
>>>
>>>> - Is your session really set up initially (before the reINVITE)?
>>>> (mediaproxy reports 0/0/0 bytes)
>>>
>>> At least i have ringback tone. Then, when the call is answered i
>>> have an OK and a ACK message coming to my SER box, then inmediatly
>>> the reINVITE message arrives Asterisk box.
>>>
>>>
>>> For what i can see from the debug the "nat=yes" is never reached
>>> because the caller has a "valid ip" and therefore the first "if" in
>>> the statament
>>>
>>> if (method=="INVITE" && client_nat_test("3")) {
>>> # INSERT YOUR IP ADDRESS HERE
>>> record_route_preset("64.76.148.246:5060;nat=yes");
>>> xlog("L_INFO", "time [%Tf] RECORD ROUTE SECTION :
>>> invite & client_nat_test(3) TRUE ,record_route_preset [%rm]\n");
>>> } else if (method!="REGISTER") {
>>> xlog("L_INFO", "time [%Tf] RECORD ROUTE SECTION :
>>> record_route [%rm]\n");
>>> record_route();
>>> };
>>>
>>> from the RECORD ROUTE SECTION is FALSE.
>>>
>>> Also, i don't understand why the second OK (the one from the
>>> reINVITE) is not procesed in the ONREPLY ROUTE, or at least i don't
>>> see any statement from the "xlog" in the debug. Is this normal?
>>>
>>> Thanks.!
>>> Regards,
>>>
>>> Ricardo Martinez.-
>>>
>>>
>>>> -----Mensaje original-----
>>>> De: Greger V. Teigre [mailto:greger at teigre.com]
>>>> Enviado el: Lunes, 18 de Julio de 2005 2:45
>>>> Para: Ricardo Martinez; serusers at lists.iptel.org
>>>> Asunto: Re: [Serusers] Problem : Can SER process the reINVITE
>>>> messages properly?
>>>>
>>>>
>>>> Hi Ricardo,
>>>> Thanks for a detailed analysis. Some questions:
>>>> - Is your session really set up initially (before the reINVITE)?
>>>> (mediaproxy reports 0/0/0 bytes)
>>>> - You didn't show the ngrep trace. The script uses nat=yes in
>>>> the Route
>>>> header of the INVITE to detect a nat'ed client. Can you
>>>> verify that the
>>>> reINVITE has the nat=yes?
>>>> - You haven't showed the mediaproxy log (it will show the
>>>> callers reporting
>>>> in etc). That could help (default /var/log/messages)
>>>> - You can put a log statement in the loose_route section
>>>> after the test for
>>>> nat=yes to see if use_media_proxy was called
>>>>
>>>> g-)
>>>>
>>>> Ricardo Martinez wrote:
>>>>> Hello.
>>>>> I'm having problems trying to make SER, NAT'd endpoints
>>>> and reINVITE
>>>>> work together.
>>>>> I was using the "gw-pstn3.07.cfg" file from onsip.org to do some
>>>>> tests, and this is what i have. In one side i have an
>> Asterisk with
>>>>> an endpoint registered in it (let's call it A). In the
>> other side i
>>>>> have a PAP2 under NAT (let's call it B).
>>>>>
>>>>>
>>>>> A ---------- Asterisk ----------- SER ----------- B (NAT'd)
>>>>> 200.0.0.7 200.0.0.6 200.0.0.5
>>>>> 10.0.0.4
>>>>>
>>>>> When i make a call from "A" to "B" this is what i see (in terms of
>>>>> SDP). Looking from SER.
>>>>>
>>>>> A --------- Asterisk ------------ SER ------------ B (NAT'd)
>>>>> Public:
>>>>> 200.0.0.4
>>>>> 200.0.0.7 200.0.0.6 200.0.0.5
>>>> Inside:
>>>>> 10.0.0.1
>>>>>
>>>>> INVITE
>>>>> c:200.0.0.6:19996
>>>>> ------------------->
>>>>> INVITE
>>>>> c:200.0.0.5:35010
>>>>> ---------------->
>>>>>
>>>>>
>>>>> Caller Via Called Status
>>>>> Duration Codec Type Traffic
>>>>>
>>>> --------------------------------------------------------------
>>>> ------------
>>>>> 200.0.0.6:19996 - 200.0.0.5:35010 - ?.?.?.?:? inactive 0'04"
>>>>> Unknown Audio 0/0/0
>>>>>
>>>>> Total traffic: 0bps/0bps/0bps (in1/in2/out)
>>>>> Session count: 1
>>>>>
>>>>> So far is ok..........and the phone is answered
>>>>> OK
>>>>> c:10.0.0.1:16440
>>>>> <---------------- (the phone is
>>>>> answered)
>>>>> OK
>>>>> c:200.0.0.5:35010
>>>>> <---------------------
>>>>>
>>>>> reINVITE
>>>>> c:200.0.0.7:19996
>>>>> --------------------->
>>>>> reINVITE
>>>>> c:200.0.0.7:19996
>>>>> ---------------->
>>>>>
>>>>> OK
>>>>> c:10.0.0.1:16440
>>>>> <----------------
>>>>> OK
>>>>> c:10.0.0.1:16440
>>>>> <---------------------
>>>>>
>>>>> Finally according to the "session" information :
>>>>>
>>>>> Caller Via Called
>>>>> Status Duration Codec Type Traffic
>>>>>
>>>> --------------------------------------------------------------
>>>> --------------
>>>>> ----------
>>>>> 200.0.0.6:19996 - 200.0.0.5:35010 - 200.0.0.7:16420 inactive
>>>>> 0'26" G729 Audio 0/11.48k/11.48k
>>>>>
>>>>> Total traffic: 0bps/0bps/0bps (in1/in2/out)
>>>>> Session count: 1
>>>>> And the audio is only in one way. :(
>>>>>
>>>>> So. you can see the reINVITE message apparently is not being
>>>>> processed as a call to a NAT'd endpoint and therefore is not using
>>>>> the mediaproxy, you can see the second "OK" messsage has
>> the invalid
>>>>> IP from the NAT'd user is in his sdp information.
>>>>> As i said it before i am using the gw-pstn configuration
>>>> file from the
>>>>> onsip.org and as far as i can remember this configuration
>> can handle
>>>>> the reINVITE? isn't
>>>>> I'm also using the last version of the mediaproxy (1.3.1).
>>>>> Can someone tell me what i'm doing wrong?
>>>>>
>>>>> Hope someone could help me here.
>>>>> Thanks in advance.
>>>>> Regards...
>>>>>
>>>>> Ricardo Martinez.-
>>>>>
>>>>> _______________________________________________
>>>>> Serusers mailing list
>>>>> serusers at lists.iptel.org
>>>>> http://lists.iptel.org/mailman/listinfo/serusers
More information about the sr-users
mailing list