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 <mico...@gmail.com <mailto:mico...@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
    <mico...@gmail.com <mailto:mico...@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
        <ushac...@gmail.com <mailto:ushac...@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@lists.sip-router.org  <mailto:sr-users@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

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to