Hi Daniel, thank you for the tip, we may upgrade to 3.2 soon, in which case we could use
the remove_body() function as well.
Also, I did not know about the t_reply function either, txs a lot for the help
----------------------------------------
Date: Mon, 27 Feb 2012 21:53:37 +0100
From: miconda(a)gmail.com
To: sr-users(a)lists.sip-router.org
CC: fborot(a)hotmail.com
Subject: Re: [SR-Users] FW: Dropping 183 and sending
180
On 2/27/12 7:25 PM, Fabian Borot wrote:
> txs a lot Alex, I will try it and let you know
the results, sounds like a better idea.
You may want to remove the body as well, in the case
it has a sdp you
dont want to be sent out -- see the functions in
textops/textopsx modules.
There is also the alternative of using
t_reply("180", "...") in an
onreply_route[xyz] set for the invite, where you match
the 183 and drop
it after sending 180.
Cheers,
Daniel
>
>
> ----------------------------------------
>> From: fborot(a)hotmail.com
>> To: users(a)lists.kamailio.org
>> Subject: Dropping 183 and sending 180
>> Date: Mon, 27 Feb 2012 12:34:05 -0500
>> Hello
>> We need to implement this scenario:
>> client -> proxy --> provider
>> The provider sends 183 with SDP and we need
to drop it and send 180 instead. I managed to do it like this:
>> 1- on_reply block, I catch the 183 if it
comes, call a route block named "DROP_180" then drop it:
>> if ($rs == "183")
>> {
>> route(DROP_180);
>> drop();
>> }
>> 2- on the new route block
"DROP_180" I use the command send_reply(180, "Ringing")
>> route[DROP_180] {
>> xlog("L_INFO","mylog: On Route
DROP_180.");
>> send_reply(180,"Ringing");
>> }
>> I had to do it on a separate block because
the send_reply command could not be used on the same on_reply block, also I had to send
the 180 first before the 183 is dropped because the drop() apparently stops the script
execution and the 180 was not sent
>> The idea works fine, BUT the To tag on the
locally generated 180 is not the same as the one on the original 183 message. After the
progress (183 message), it comes the 200 OK, which we forward downstream unaltered. Now,
the client seems to ignore the 200 OK, (there is no ACK), we think that since the To tag
on the original 183 and the 200 OK does not match the one on the 180 that is why the
customer is processing the 200 OK. Any ideas here?
>> txs a lot
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users mailing list
> sr-users(a)lists.sip-router.org
--
Daniel-Constantin Mierla --
http://www.asipto.com