earlier today I commented out the whole route(NATMANAGE) from
MANAGE_FAILURE route, that broke the NAT.
But with your condition it works fine. thanks!
Only I don't understand the $du/$ru thing yet.
On 6/5/13, Daniel-Constantin Mierla <mico...@gmail.com> wrote:
> 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 <mico...@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 <23h...@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@127.0.0.1:5070;transport=udp>
>>>>>
>>>>> Could that ever work this way?
>>>>>
>>>>> On 6/4/13, Daniel Tryba <dan...@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@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@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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
