Attached is the full test config I am using.. I have gone back and forth trying a few things, but this is the latest.. If you have a another way to achieve the same result, I am open to change how I'm trying to do it. Thanks again for your help. Kent -----Original Message----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Tuesday, September 23, 2008 5:50 AM To: Kent Pirlo Cc: users Subject: Re: [Kamailio-Users] nested redirect 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@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:...@...> >> 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@gmail.com] >> Sent: Tuesday, September 16, 2008 5:10 AM >> To: kentp(a)globalpops.com >> Cc: users(a)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(a)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; >>> } >>> } >>> >>> >>> >>>