[SR-Users] Can't work around double SDP rewrite issue with rtpengine and config script SDP manipulation

[Daniel-Constantin Mierla]

The loose_route() is marking local Route headers for deletion, so after
the msg_apply_changes() you don't see them. It should work fine if you
do not need to inspect them afterwards, but if you are not sure, it is
recommended do it before.

Cheers,
Daniel

On 02.06.20 09:49, George Diamantopoulos wrote:
> Daniel, that worked instantly, thank you!
>
> Care to elaborate on how msg_apply_changes() interferes with
> loose_route? I also remember msg_apply_changes() complaining if called
> after record_route(), is it related?
>
> On Mon, 1 Jun 2020 at 21:24, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Hello,
>
>     use msg_apply_changes just after replace_body_str(), eventually
>     before loose routing processing for requests within dialog.
>
>     Cheers,
>     Daniel
>
>     On 01.06.20 13:34, George Diamantopoulos wrote:
>>     Hello all,
>>
>>     I'm facing one of those cases where I need to edit the body of a
>>     SIP message, which is then to be fed to rtpengine for processing.
>>     Although I've taken every precaution I've read about on this list
>>     and elsewhere, I can't prevent the edited line from appearing
>>     twice in the outgoing message.
>>
>>     The configuration file used is huge, so I'm going to try to
>>     provide a high-level overview here. But first, the things (I
>>     think) I know to be requirements, and which I have striven to meet:
>>
>>       * If SDP is to be edited, then all such processing is to be
>>         carried out in such a way in the script, so that
>>         msg_apply_changes() is run as many times as needed before
>>         rtpengine offer/answer/manage is called.
>>       * rtpengine offer/answer/manage is to be called only once per
>>         script iteration
>>       * msg_apply_changes can only be called in a request route, or
>>         in the core reply_route (i.e. *not* in tm-managed
>>         on_reply_route[XXX] blocks)
>>
>>     In my case, additionally the following are true:
>>
>>       * SDP processing (other than the one performed by rtpengine)
>>         takes place in one common route for all cases where it needs
>>         to happen. These are two at the moment in my scenario:
>>           o Early in the WITHINDLG route (of the example config file)
>>           o After the sanity checks in the reply_route (of the
>>             example config file)
>>       * msg_apply changes() is called once, for each script iteration:
>>           o right before rtpengine_manage() is called, provided that
>>             t_is_request_route() returns true (so that I don't
>>             accidentally call it from a branch route or anything)
>>               + rtpengine_manage() is called in its own route, which
>>                 is very similar to the example config file's
>>                 "NATMANAGE" route. Since NATMANAGE is called in all
>>                 branch and on_reply_routes, I employ
>>                 t_is_request_route() here to make sure it won't
>>                 execute in those cases.
>>           o at the end of the "core" reply_route
>>
>>     Now regarding the actual config-file-controlled SDP manipulation,
>>     it only consists of a single call to replace_body_str(). The
>>     purpose is to edit a line in the message body from something like:
>>
>>       * a=fmtp:101 0-16
>>
>>     to something along the lines of:
>>
>>       * a=fmtp:101 0-15
>>
>>     For replies, this works as expected.
>>
>>     For in-dialog requests, however, I end up with both the original
>>     and the edited lines:
>>     a=fmtp:101 0-16 (the original line)
>>     ... other SDP stuff ...
>>     a=fmtp:101 0-15 (the edited line)
>>
>>     If anyone could point out any misconceptions I have about
>>     msg_apply_changes, SDP rewriting from the script and
>>     rtp_engine_X() interoperability, I would be more than grateful.
>>
>>     Thank you in advance and I apologize for the long read.
>>
>>     Best regards,
>>     George Diamantopoulos
>>
>>     _______________________________________________
>>     Kamailio (SER) - Users Mailing List
>>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>     -- 
>     Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>     Funding: https://www.paypal.me/dcmierla
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200603/3120ba38/attachment.html>