[Kamailio-Users] nested redirect

[Daniel-Constantin Mierla]

Hello,

sorry, you were right, there was a pcap attachment! The ACK looks ok. 
Seems that ACK is quickly discarded by the script. Is the config  you 
pasted in your first email complete? I need to see it all the understand 
how the ack get's routed and where could be dropped by the config.

Cheers,
Daniel



On 09/17/08 18:42, Kent Pirlo wrote:
> There should have been a 20k attachment.. redirect.cap.. from tethereal.
> Let me know if you do not have it, and I will re-send it.
>
> kent
>
> -----Original Message-----
> From: Daniel-Constantin Mierla [mailto:miconda at gmail.com]
> Sent: Wednesday, September 17, 2008 6:43 AM
> To: Kent Pirlo
> Cc: users
> Subject: Re: [Kamailio-Users] nested redirect
>
> Hello,
>
> what you sent is the debug from kamailio/openser, which is useful, but I
> would need the sip messages, you can use ngrep for that, do
> ngrep -d any -qt -W byline port 5060
>
> on your openser/kamailio server and send the output.
>
> Thanks,
> Daniel
>
>
> On 09/17/08 02:22, Kent Pirlo wrote:
>   
>> ... is my core switch,
>> ... is my openser/Kamailio redirect server
>> ... is a redirect server from a carrier of ours that returns a billing TN in contact header..
>>
>>
>> Here is the debug of the incoming ACK from the core switch after being sent the 300...
>>
>>
>> Sep 16 15:49:50 [6505] DBG:core:parse_msg: SIP Request:
>> Sep 16 15:49:50 [6505] DBG:core:parse_msg:  method:  <ACK>
>> Sep 16 15:49:50 [6505] DBG:core:parse_msg:  uri:     <sip:... at ...>
>> Sep 16 15:49:50 [6505] DBG:core:parse_msg:  version: <SIP/2.0>
>> Sep 16 15:49:50 [6505] DBG:core:parse_headers: flags=2
>> Sep 16 15:49:50 [6505] DBG:core:parse_to_param: tag=391854ebdd4d0c63cf50836cbb12191e-6708
>> Sep 16 15:49:50 [6505] DBG:core:parse_to: end of header reached, state=29
>> Sep 16 15:49:50 [6505] DBG:core:parse_to: display={},
>> Sep 16 15:49:50 [6505] DBG:core:get_hdr_field: <To> [75];
>> Sep 16 15:49:50 [6505] DBG:core:get_hdr_field: to body
>> Sep 16 15:49:50 [6505] DBG:core:get_hdr_field: cseq <CSeq>: <1> <ACK>
>> Sep 16 15:49:50 [6505] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKdce3ac34730f843a5a9b9c7002690f22>; state=16
>> Sep 16 15:49:50 [6505] DBG:core:parse_via: end of header reached, state=5
>> Sep 16 15:49:50 [6505] DBG:core:parse_headers: via found, flags=2
>> Sep 16 15:49:50 [6505] DBG:core:parse_headers: this is the first via
>> Sep 16 15:49:50 [6505] DBG:core:receive_msg: After parse_msg...
>> Sep 16 15:49:50 [6505] DBG:core:receive_msg: preparing to run routing scripts...
>> Sep 16 15:49:50 [6505] DBG:sl:sl_filter_ACK: to late to be a local ACK!
>> Sep 16 15:49:50 [6505] DBG:core:destroy_avp_list: destroying list (nil)
>> Sep 16 15:49:50 [6505] DBG:core:receive_msg: cleaning up
>>
>>
>>
>>
>> -----Original Message-----
>> From: Daniel-Constantin Mierla [mailto:miconda at gmail.com]
>> Sent: Tuesday, September 16, 2008 5:10 AM
>> To: kentp at globalpops.com
>> Cc: users at lists.kamailio.org
>> Subject: Re: [Kamailio-Users] nested redirect
>>
>> Hello,
>>
>> can you post here the SIP messages? Will help to spot if there is
>> anything wrong with the ACK or something else in the signaling.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 09/13/08 04:11, kentp at globalpops.com wrote:
>>
>>     
>>> i have a simple redirect server working:
>>>
>>> Call comes from switch (A) to kamailio redirect server (B)..
>>> (B) runs perl script to determine route
>>> (B) sends Stateless 300 redirect reply to (A).
>>> (A) sends ACK to (B).
>>>
>>> Now, I need to add a nested redirect...
>>>
>>> call comes from sitch (A) to kamailio redirect server (B)..
>>> (B) then needs to send the call to third party proxy (C)..
>>> (C) will return 302 redirect..
>>> (B) sends ACK to (C)
>>> (B) needs to read the contact header, then run perl script to determine route (using the contact value
>>> returned from (c))
>>> (B) then sends 300 redirect back to (A).
>>> (A) sends ACK back to (B)
>>>
>>>
>>> so far i have been trying something like this, but the final (A) ACK gets ignored and (B) keeps sending
>>> multiple 300's to (A):
>>>
>>> route {
>>>       route(1);
>>> }
>>>
>>> route[1] {
>>>               t_on_reply("1");
>>>               t_on_failure("2");
>>>               if (!t_relay("proxy.server.c:5060","0x02")) {
>>>                               sl_reply_error();
>>>               }
>>> onreply_route[1] {
>>>         if(t_check_status("302")){
>>>                 $var(lrn_from_bv) = $ct;
>>>         }
>>> }
>>> failure_route[2] {
>>>
>>>         if (t_check_status("3[0-9][0-9]")) {
>>>                 route(2);
>>>                 exit;
>>>         }
>>> route[2] {
>>>               if(perl_exec("callcheck")){
>>>                       avp_pushto("$ru", "$avp(s:routes)/g");
>>>                       t_reply("300","Go Here");
>>>                       exit;
>>>               }
>>>         }
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.kamailio.org
>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>       
>> --
>> Daniel-Constantin Mierla
>> http://www.asipto.com
>>
>>     
>
> --
> Daniel-Constantin Mierla
> http://www.asipto.com
>
>   

-- 
Daniel-Constantin Mierla
http://www.asipto.com