[SR-Users] if (t_check_status("486|408"))
Daniel-Constantin Mierla
miconda at gmail.com
Wed Jun 5 22:18:36 CEST 2013
I couldn't find if many parameters with same name are allowed in SIP
URI, in headers they are not.
Try to put:
if(t_is_branch_route())
as condition for add_rr_param(...)
Cheers,
Daniel
On 6/5/13 7:18 PM, hiro wrote:
> I'm just using the default kamailio.cfg for kamailio 4.0.
>
> add_rr_param() gets called in branch_route[MANAGE_BRANCH] and
> failure_route[MANAGE_FAILURE]
>
> i commented out the latter and the phone gets the replies just fine now!
> But the rtp gets sent to the originally called phone from the port
> that got originally got presented to that phone in the first INVITE.
>
> On 6/5/13, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>> 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 *
>>
>>
>> _______________________________________________
>> 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 *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130605/e2cc5ff9/attachment-0001.html>
More information about the sr-users
mailing list