[SR-Users] Reply 503 was replaced to 500

[Daniel-Constantin Mierla]

Hello,

you have to use append_hf() in the onreply route.

Cheers,
Daniel

On 7/18/12 7:20 AM, Uri Shacked wrote:
>
> Hi
>
> I tried the "change_reply_status".
>
> The problem with it is that i need to do "append_to_reply" as well. 
> The first one can be called only on the "on reply" route, and the 
> second on the "on failure" route.
>
> And as i notice, doing "append_to_reply" with no "t_reply" does not 
> really append anything... so it looks like I will have to do "t_reply" 
> and deal with the to_tag later.
>
> Thanks,
>
> Uri
>
> On Tue, Jul 17, 2012 at 8:18 PM, Daniel-Constantin Mierla 
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Hello,
>
>     sending a >=300 reply is for an not-established dialog, which
>     eventually can be forked by proxy, meaning many 1xx replies can
>     get to caller, then many >=300 replies can get to the proxy which
>     will chose which one to use for sending back to the caller.
>
>     Doing a t_reply(...) with a different code than the received one
>     is like having two branch, one locally and one from where the
>     reply is received, but you decide to reply from the local one. So
>     if the caller device has problems with this case, the it will have
>     problems with serial/parallel forking.
>
>     For accounting you can save incoming to-tag in an avp and store it
>     in a separate column in acc table. But setting the to-tag for
>     t_reply() is not possible at this time.
>
>     Btw, have you tried instead the change_reply_status() function?
>
>     http://kamailio.org/docs/modules/stable/modules/textopsx.html#textopsx.change_reply_status
>
>     Cheers,
>     Daniel
>
>
>     On 7/17/12 2:23 PM, Uri Shacked wrote:
>>
>>     Hi,
>>
>>     Here is the problem with the solution to sending different reply
>>     then the once I receive:
>>
>>     I check if the reply is 603. If so, i did t_drop_replies and then
>>     t_reply with the reply i wanted to send back. 500 with
>>     append_to_reply something....
>>
>>     The problem is that on the 500 that i send back, the to_tag is
>>     not the same to_tag that i received with the 603.
>>
>>     That makes some problems on the sip and lots of problems on the
>>     CDR creation (it is based on to_tag as well).
>>
>>     Any ideas?
>>
>>     How do i make it the same to_tag? Removing a header and
>>     recreating it seems very dirty for it.....
>>
>>     BR,
>>
>>     Uri
>>
>>     On Mon, Jun 25, 2012 at 10:25 AM, Daniel-Constantin Mierla
>>     <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>
>>         Hello,
>>
>>         this 503 to 500 is a requirement from RFC, to prevent
>>         propagation of blacklisting/disabling destination hosts. I
>>         don't remember right now any configuration option for it, but
>>         you can try to enforce it from the failure route, like:
>>
>>         t_reply("503", "...");
>>
>>         Cheers,
>>         Daniel
>>
>>
>>         On 6/24/12 4:30 PM, Uri Shacked wrote:
>>>         I just read the topic - "_Copy reason field from 503 to 500. _"
>>>         Is there a way to change it if i want to send back the
>>>         original leg 2 503 reply?
>>>
>>>         On Sun, Jun 24, 2012 at 4:17 PM, Uri Shacked
>>>         <ushacked at gmail.com <mailto:ushacked at gmail.com>> wrote:
>>>
>>>             Hi,
>>>             Kamailio server is behind our company's softswitch and
>>>             acts as a sip application server.
>>>             I notice that there are calls that the softswitch
>>>             replied with 503 "service unavailable" and kamailio sent
>>>             to the originator leg 500 "service unavaileable".
>>>             When kamailio recieved 504 or 502 it sends them back as
>>>             is. shouldn't it be the same with 503?
>>>             It also does not have a "to tag" in the CDR. And the "to
>>>             tag" in the 503 that was recieved is not equal to the
>>>             500 reply "to tag"  kamailio sent back.
>>>             any ideas?
>>>             BR,
>>>             Uri
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>         sr-users at lists.sip-router.org  <mailto:sr-users at lists.sip-router.org>
>>>         http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>         -- 
>>         Daniel-Constantin Mierla -http://www.asipto.com  <http://www.asipto.com/>
>>         http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>>         Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>>         Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>>
>>
>
>     -- 
>     Daniel-Constantin Mierla -http://www.asipto.com  <http://www.asipto.com/>
>     http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>     Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 -http://asipto.com/u/katu
>     Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 -http://asipto.com/u/kpw
>
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120718/15a5c771/attachment-0001.htm>