[SR-Users] if (t_check_status("486|408"))
Daniel-Constantin Mierla
miconda at gmail.com
Wed Jun 5 09:41:46 CEST 2013
Are you executing the route block for NAT handling in request_route and
failure_route blocks? It should be done in branch route or only once in
request_route. Look for add_rr_param() and see how many times it is
executed for a branch (if executed in request_route, then it is for all
branches at least one time).
Cheers,
Daniel
On 6/4/13 10:57 PM, hiro wrote:
> actually, I now see my last message is wrong.
> I've compared the 200 OKs that gets sent from freeswitch to my phone
> after the busy error and after direct voicemail routing from LOCATION
> when user is offline. Both 200 OKs look the same with one exception:
> The one that doesn't work had nat=yes two times here:
>
> Record-Route: <sip:77.13.20.156;r2=on;lr=on;nat=yes;nat=yes>
> Record-Route: <sip:77.13.20.156;transport=tcp;r2=on;lr=on;nat=yes;nat=yes>
>
>
> On 6/4/13, hiro <23hiro at gmail.com> wrote:
>> ok. right now from tcpdump I can see the session progress and OK
>> messages are sent to the correct ip:port of my phone, but either the
>> phone doesn't receive it or it doesn't process it.
>>
>> I assume the problem to be the headers sent by freeswitch, and perhaps
>> not changed appropriately by kamailio, but I'm not sure:
>> Call id and Cseq are the same as in RINGING, but contact header has
>> freeswitch's IP (on the same server as kamailio)
>> Contact: <sip:3 at 127.0.0.1:5070;transport=udp>
>>
>> Could that ever work this way?
>>
>> On 6/4/13, Daniel Tryba <daniel at pocos.nl> wrote:
>>> On Tuesday 04 June 2013 12:07:35 hiro wrote:
>>>> Sometimes it also seemed that kamailio was sending the INVITE to the
>>>> phone instead of to freeswitch, or when i played around between
>>>> changing $du or $ru the INVITE gets sends to freeswitch but with the
>>>> wrong URI pointing to the phone instead of 127.0.0.1:5070 which is
>>>> where freeswitch is listening.
>>>> I guess it would be easier to reproduce if that random factor wasn't
>>>> there, but at least it's failing most of the time, only in different
>>>> ways.
>>>> I had hoped I could get at least confirmation that it "works here" to
>>>> keep me going :P
>>>> I will test with xlog when I can test at home again which would at
>>>> least exclude NAT issues.
>>> It works here :)
>>>
>>> I know your pain. I spend days figuring out the magic trick was to set
>>> $du
>>> to
>>> null (which I stumbled upon by accident). Without $du=$null traffic was
>>> being
>>> routed (seemingly random) to either the registered phone or the actual
>>> voicemail server.
>>>
>>> # route to voicemail server
>>> route[TOVOICEMAIL] {
>>> if(!is_method("INVITE"))
>>> return;
>>>
>>> # check if VoiceMail server IP is defined
>>> if (strempty($sel(cfg_get.voicemail.srv_ip))) {
>>> xlog("SCRIPT: VoiceMail routing enabled but IP not
>>> defined\n");
>>> return;
>>> }
>>>
>>> if($avp(dst_voicemail))
>>> {
>>> $du=$null;
>>> $ru = "sip:tovm-" + $avp(dst_voicemail) + "@" +
>>> $sel(cfg_get.voicemail.srv_ip) + ":" + $sel(cfg_get.voicemail.srv_port);
>>>
>>> route(RELAY);
>>>
>>> exit;
>>> }
>>>
>>> return;
>>> }
>>>
>>> failure_route[MANAGE_FAILURE] {
>>> ....
>>> # serial forking
>>> # - route to voicemail on busy or no answer (timeout)
>>> if (t_check_status("486|408")) {
>>> route(CALLREDIRECT);
>>> route(TOVOICEMAIL);
>>> exit;
>>> }
>>> ....
>>> }
>>>
>>> --
>>>
>>> POCOS B.V. - Croy 9c - 5653 LC Eindhoven
>>> Telefoon: 040 293 8661 - Fax: 040 293 8658
>>> http://www.pocos.nl/ - http://www.sipo.nl/
>>> K.v.K. Eindhoven 17097024
>>>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
* http://asipto.com/u/katu *
More information about the sr-users
mailing list