Can't work around double SDP rewrite issue with rtpengine and config script SDP manipulation
1 Jun
2020
1 Jun
'20
1:34 p.m.
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
1 Jun
1 Jun
1:38 p.m.
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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2:14 p.m.
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(a)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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
3:30 p.m.
George,
I understand. Have you considered begrudgingly adding a lightweight B2BUA such as SEMS in
the middle?
I understand it greatly increases the operational complexity and moving parts of your
setup, to say nothing of infrastructural costs. I am all for using Kamailio alone to solve
problems that the disinformation/spam of the SBC industry tells us we need a conventional
SBC to solve. I gave a presentation at the last Kamailio World[1] whose general tenor was
that all one needs is a little Kamailio, and which could be interpreted as a winding,
circumlocutory middle finger to the SBC industry. :-)
But this really does strike me as a valid use-case for an “SBC” type setup as we’ve been
made to understand the term — that is, in what Oracle/Metaswitch/Sansay/Sonus/etc would
like to have you think of as “the ordinary sense”.
RTPEngine is minimally invasive and, outside of its mandate to change the media endpoint
addresses, is designed for additive capabilities, not to fix problems or maladaptive
behaviours. Meanwhile, tweaking the SDP body, despite the existence of extensive technical
capability on the part of Kamailio, is not something a proxy should be doing; it’s just
not faithful to the endpoints’ tacit assumption that the SDP offer/answer they send is the
one being operated upon by the other party. And, as you’ve noted, it is problematic to
both tweak the SDP body and press RTPEngine into service simultaneously.
There may be — in fact, it’s likely — a solution to your most immediate technical problem,
though I’m not sure offhand. But for the sake of manageability and conceptual integrity to
your voice architecture going forward, I would urge you to reconsider whether this is the
best way of doing things overall.
... unless you’re already well past that point, to which I think your references to the
size and complexity of your config allude. :-) In that case, a nihilistic attitude may
better suit the dark, ghastly hue of the situation.
— Alex
[1] https://youtu.be/j-0C6eHfocI
—
Sent from mobile, with due apologies for brevity and errors.
On Jun 1, 2020, at 8:15 AM, George Diamantopoulos
<georgediam(a)gmail.com> wrote:
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(a)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.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users On Jun 1,
2020, at 7:35 AM, George Diamantopoulos <georgediam(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
8:24 p.m.
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
2 Jun
2 Jun
9:49 a.m.
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(a)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:
- 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
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
3 Jun
3 Jun
12:44 p.m.
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(a)gmail.com <mailto:miconda@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:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
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(a)lists.kamailio.org <mailto:sr-users@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
1429
days inactive
1431
days old
6 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
George Diamantopoulos