[SR-Users] if (t_check_status("486|408"))

[hiro]

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
>>
>