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

[George Diamantopoulos]

Hello Alex,

Thank you for your reply. Well, I'm interfacing with several PSTN
operators, and some of their networks' SIP endpoints (or other obscure IMS
entity there) are very picky in that if they don't like the capabilities
you serve for telephone-event (which is if they don't match theirs), then
the transaction is rejected with "488 SDP Parameter Error In SIP Request"
(or if it's a reply I'm sending, they will send a BYE immediately).

Trying to reason with them (the operators) has failed, my SIP UA provides
no way to choose these values when the SDP is created (and since it
apparently has to match the other side some static configuration wouldn't
do much here), so all I'm left with is the option of growing my config file
by yet another 50 lines... :-\

BR,
George

On Mon, 1 Jun 2020 at 14:41, Alex Balashov <abalashov at evaristesys.com>
wrote:

> George,
>
> It may be orthogonal to the answer that you seek, but I’m going to ask
> anyway: what is the overall motive underlying your SDP manipulation?
>
> It seems to me that one should reason backward from that root cause. The
> kind of SDP manipulation you are doing is seldom necessary in ordinarily
> imaginable contexts...
>
> — Alex
>
> —
> Sent from mobile, with due apologies for brevity and errors.
>
> On Jun 1, 2020, at 7:35 AM, George Diamantopoulos <georgediam at gmail.com>
> 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:
>    - Early in the WITHINDLG route (of the example config file)
>       - After the sanity checks in the reply_route (of the example config
>       file)
>    - msg_apply changes() is called once, for each script iteration:
>       - 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.
>       - 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
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200601/cbf1ab4d/attachment.html>