21 Apr
2023
21 Apr
'23
10:53 a.m.
Hi all
I wonder, if there is a documentation on what action is performed by
rtpengine_manage() on which kind reply.
Am I right, that rtpengine_manage(), on any 4XX reply causes a delete?
So if there is a re-invite (for example to switch to T.38) and the
other party replies with 488 which in turn is passed through
rtpengine_manage() the existing RTP stream is deleted from rtpengine
instead of being left running with the previously agreed codec?
Has anyone already figured out a list of what reply codes should be
exempt from calling rtpengine_manage()?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
21 Apr
21 Apr
12:49 p.m.
Benoit,
I think the most comprehensive answer for how rtpengine_manage is working
is actually looking at the code, it's quite easy to read
https://github.com/kamailio/kamailio/blob/b65c19fa29976b59403433ed8a5de4b7e…
In your case (failed reINVITE), I'd preform a test, cause
rtoengine_delete() is called in this case according to a source code. And
than it's really rtpengine itself will decide what to do with the stream,
fallback or delete.
Le ven. 21 avr. 2023 à 11:34, Benoît Panizzon <benoit.panizzon(a)imp.ch> a
écrit :
Hi all
I wonder, if there is a documentation on what action is performed by
rtpengine_manage() on which kind reply.
Am I right, that rtpengine_manage(), on any 4XX reply causes a delete?
So if there is a re-invite (for example to switch to T.38) and the
other party replies with 488 which in turn is passed through
rtpengine_manage() the existing RTP stream is deleted from rtpengine
instead of being left running with the previously agreed codec?
Has anyone already figured out a list of what reply codes should be
exempt from calling rtpengine_manage()?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
--
Best regards,
Ihor (Igor)
5:05 p.m.
Hi Ihor
if (msg->first_line.type == SIP_REPLY) {
if (msg->first_line.u.reply.statuscode>=300)
return rtpengine_delete(msg, flags);
Thanks for the hint.
I'll do the same in manage_reply but not engage rtpengine_manage() on a
status code 488 to allow fall-back on a failed re-negotiation.
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
24 Apr
24 Apr
8:46 a.m.
Hello,
actually, this also documented in the kamailio modules readme:
https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.…
"- If reply to INVITE with code >= 300 do rtpengine_delete()"
Cheers,
Henning
-----Original Message-----
From: Benoît Panizzon <benoit.panizzon(a)imp.ch>
Sent: Freitag, 21. April 2023 17:05
To: Ihor Olkhovskyi <igorolhovskiy(a)gmail.com>
Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: [SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on
reply-codes?
Hi Ihor
if (msg->first_line.type == SIP_REPLY) {
if (msg->first_line.u.reply.statuscode>=300)
return rtpengine_delete(msg, flags);
Thanks for the hint.
I'll do the same in manage_reply but not engage rtpengine_manage() on a status code
488 to allow fall-back on a failed re-negotiation.
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to
sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
10:02 a.m.
On Apr 24, 2023, at 2:46 AM, Henning Westerholt
<hw(a)gilawa.com> wrote:
Hello,
actually, this also documented in the kamailio modules readme:
https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.…
"- If reply to INVITE with code >= 300 do rtpengine_delete()"
Yeah, it is.
But what I think Benoît was really getting at is a question not addressed by the
documentation or the source code: do I really want to 'delete' for _any_ >= 300
reply code, or are there corner cases, like 488 for a reinvite (where the standards say
the call must continue according to previous parameters if a reinvite fails)? And if so,
are there any others, or is 488 truly it?
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
10:29 a.m.
On 24 Apr 2023, at 10:02, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Agree that the reinvite case is interesting, exactly because of the possible fallback to
original state.
I guess there are a number of possible codes, like a timeout (408) or system problem (5xx)
in addition to the “correct” code 488 where fallback could happen.
/O
On Apr 24, 2023, at 2:46 AM, Henning Westerholt
<hw(a)gilawa.com> wrote:
Hello,
actually, this also documented in the kamailio modules readme:
https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.…
"- If reply to INVITE with code >= 300 do rtpengine_delete()"
Yeah, it is.
But what I think Benoît was really getting at is a question not addressed by the
documentation or the source code: do I really want to 'delete' for _any_ >= 300
reply code, or are there corner cases, like 488 for a reinvite (where the standards say
the call must continue according to previous parameters if a reinvite fails)? And if so,
are there any others, or is 488 truly it? 
4:17 p.m.
On 24.04.23 10:29, Olle E. Johansson wrote:
rtpengine_manage() should be used in failure_route only when knowing
that the call is failing completely. In failure route it should not be
used for the purpose of an offer, that is for branch_route usage. The
rtpengine offer()/answer()/delete() functions are there to use when
specific needs pop up.
Of course, then config conditions can be used to exclude cases as needed.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
On 24 Apr 2023, at 10:02, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Agree that the reinvite case is interesting, exactly because of the possible
fallback to original state.
I guess there are a number of possible codes, like a timeout (408) or system problem
(5xx) in addition to the “correct” code 488 where fallback could happen.
On Apr 24, 2023, at 2:46 AM, Henning Westerholt
<hw(a)gilawa.com> wrote:
Hello,
actually, this also documented in the kamailio modules readme:
https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.…
"- If reply to INVITE with code >= 300 do rtpengine_delete()"
Yeah, it is.
But what I think Benoît was really getting at is a question not addressed by the
documentation or the source code: do I really want to 'delete' for _any_ >= 300
reply code, or are there corner cases, like 488 for a reinvite (where the standards say
the call must continue according to previous parameters if a reinvite fails)? And if so,
are there any others, or is 488 truly it?
25 Apr
25 Apr
8:39 a.m.
On 24 Apr 2023, at 16:17, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
On 24.04.23 10:29, Olle E. Johansson wrote:
rtpengine_manage() should be used in failure_route only when knowing
that the call is failing completely. In failure route it should not be
used for the purpose of an offer, that is for branch_route usage. The
rtpengine offer()/answer()/delete() functions are there to use when
specific needs pop up.
Of course, then config conditions can be used to exclude cases as needed.
So how do we handle a reinvite that is not accepted and tell RTPengine to fall back?
Consider:
1. Successfull INVITE/200OK/ACK with alaw only
- RTPengine setup and active
2. Re-invite with video added
- RTP engine active with video
3. Re-invite denied with 488
- How do we tel RTPengine to skip video?
In many cases a re-invite is just hold/off hold or mute/off mute so it’s no problem, But
if we have significant modification of media - ports, types and codecs (if RTPengine
transcodes) a failed re-invite could be hurtful to the call. Unless there’s some code in
RTPengine to handle this.
/O
On 24 Apr 2023, at 10:02, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Agree that the reinvite case is
interesting, exactly because of the possible fallback to original state.
I guess there are a number of possible codes, like a timeout (408) or system problem
(5xx) in addition to the “correct” code 488 where fallback could happen. On Apr 24, 2023, at 2:46 AM, Henning Westerholt
<hw(a)gilawa.com> wrote:
Hello,
actually, this also documented in the kamailio modules readme:
https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.…
"- If reply to INVITE with code >= 300 do rtpengine_delete()"
Yeah,
it is.
But what I think Benoît was really getting at is a question not addressed by the
documentation or the source code: do I really want to 'delete' for _any_ >= 300
reply code, or are there corner cases, like 488 for a reinvite (where the standards say
the call must continue according to previous parameters if a reinvite fails)? And if so,
are there any others, or is 488 truly it? 
2:04 p.m.
On 25/04/2023 02.39, [EXT] Olle E. Johansson wrote:
So how do we handle a reinvite that is not accepted
and tell RTPengine to fall back?
Consider:
1. Successfull INVITE/200OK/ACK with alaw only
- RTPengine setup and active
2. Re-invite with video added
- RTP engine active with video
3. Re-invite denied with 488
- How do we tel RTPengine to skip video?
In many cases a re-invite is just hold/off hold or mute/off mute so it’s no problem, But
if we have significant modification of media - ports, types and codecs (if RTPengine
transcodes) a failed re-invite could be hurtful to the call. Unless there’s some code in
RTPengine to handle this.
Currently there's no way to signal these types of events to rtpengine,
and so there's no automatic handling of them. It would be a great
feature to have, just someone needs to implement it 🤡
An additional complication is that an event such as a 488 might require
cooperation from the SIP layer to rectify (depending on the exact
scenario), e.g. another invite/ok subsequent to the 488, but without
knowledge of the opposite-side device. In general this would go beyond
the scope of what a plain SIP proxy does.
One workaround (kludge/hack) I've seen is to store the last successful
SDP somewhere, then intercept and drop the 488 and replay the last
offer/answer with the stored SDPs. (Absolutely not something I would
consider a proper solution...)
For the concrete example you've given, that currently wouldn't even work
with explicit signalling to rtpengine as we don't support manipulating
entire media sections yet. That's a feature that should™ hopefully™ be
coming soon™.
Cheers
4:59 p.m.
On 25 Apr 2023, at 14:04, Richard Fuchs
<rfuchs(a)sipwise.com> wrote:
On 25/04/2023 02.39, [EXT] Olle E. Johansson wrote:
It’s just code, right?
So how do we handle a reinvite that is not
accepted and tell RTPengine to fall back?
Consider:
1. Successfull INVITE/200OK/ACK with alaw only
- RTPengine setup and active
2. Re-invite with video added
- RTP engine active with video
3. Re-invite denied with 488
- How do we tel RTPengine to skip video?
In many cases a re-invite is just hold/off hold or mute/off mute so it’s no problem, But
if we have significant modification of media - ports, types and codecs (if RTPengine
transcodes) a failed re-invite could be hurtful to the call. Unless there’s some code in
RTPengine to handle this.
Currently there's no way to signal these types of events to rtpengine, and so
there's no automatic handling of them. It would be a great feature to have, just
someone needs to implement it 🤡
An additional complication is that an event such as a
488 might require cooperation from the SIP layer to rectify (depending on the exact
scenario), e.g. another invite/ok subsequent to the 488, but without knowledge of the
opposite-side device. In general this would go beyond the scope of what a plain SIP proxy
does.
Kamailio is way more than a “plain SIP proxy” - ha ha. But I understand what
you mean.
One workaround (kludge/hack) I've seen is to store the last successful SDP somewhere,
then intercept and drop the 488 and replay the last offer/answer with the stored SDPs.
(Absolutely not something I would consider a proper solution…)
That will break more
than it helps.
But is there a way to “revert” back. Let’s say I store the last successful SDPs - can I
transmit them to RTPengine to revert. If I have the dialog module I could very well save
them within the context of the dialog.
Would be nice to have a “rtpengine_revert()” command that resets back to the state before
the last INVITE, the last successful state with complete offer and answer.
For the concrete example you've given, that currently wouldn't even work with
explicit signalling to rtpengine as we don't support manipulating entire media
sections yet. That's a feature that should™ hopefully™ be coming soon™.
Let’s pray to the gods of realtime communication then :-)
Thank you for your answer.
/O
6 p.m.
On 25/04/2023 10.59, [EXT] Olle E. Johansson wrote:
Yeah that's exactly what I was talking about. You can replay the last
successful rtpengine_offer()/_answer() with a stored SDP, and that would
revert the call to the last state. That's what read_sdp_pv and
write_sdp_pv config params are for.
One workaround
(kludge/hack) I've seen is to store the last successful SDP somewhere, then intercept
and drop the 488 and replay the last offer/answer with the stored SDPs. (Absolutely not
something I would consider a proper solution…)
That will break more than it helps.
But is there a way to “revert” back. Let’s say I store the last successful SDPs - can I
transmit them to RTPengine to revert. If I have the dialog module I could very well save
them within the context of the dialog.
Would be nice to have a “rtpengine_revert()” command
that resets back to the state before the last INVITE, the last successful state with
complete offer and answer.
That's what a theoretical handling of 488 etc would entail, yes...
Cheers
26 Apr
26 Apr
8:27 a.m.
On 25 Apr 2023, at 18:00, Richard Fuchs
<rfuchs(a)sipwise.com> wrote:
On 25/04/2023 10.59, [EXT] Olle E. Johansson wrote:
Yeah that's exactly what I was talking
about. You can replay the last successful rtpengine_offer()/_answer() with a stored SDP,
and that would revert the call to the last state. That's what read_sdp_pv and
write_sdp_pv config params are for.
Beautiful
One
workaround (kludge/hack) I've seen is to store the last successful SDP somewhere, then
intercept and drop the 488 and replay the last offer/answer with the stored SDPs.
(Absolutely not something I would consider a proper solution…)
That will break more
than it helps.
But is there a way to “revert” back. Let’s say I store the last successful SDPs - can I
transmit them to RTPengine to revert. If I have the dialog module I could very well save
them within the context of the dialog. Would be nice
to have a “rtpengine_revert()” command that resets back to the state before the last
INVITE, the last successful state with complete offer and answer.
That's what a theoretical handling of 488 etc would entail, yes… 
373
days inactive
378
days old
12 comments
8 participants
participants (8)
-
Alex Balashov -
Benoît Panizzon -
Daniel-Constantin Mierla -
Henning Westerholt -
Ihor Olkhovskyi -
Olle E. Johansson -
Patrick Karton -
Richard Fuchs