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()?
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/b65c19fa29976b59403433ed8a5de4b7ee...
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@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@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
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.
Hello,
actually, this also documented in the kamailio modules readme:
https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.r...
"- If reply to INVITE with code >= 300 do rtpengine_delete()"
Cheers,
Henning
-----Original Message----- From: Benoît Panizzon benoit.panizzon@imp.ch Sent: Freitag, 21. April 2023 17:05 To: Ihor Olkhovskyi igorolhovskiy@gmail.com Cc: Kamailio (SER) - Users Mailing List sr-users@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
On Apr 24, 2023, at 2:46 AM, Henning Westerholt hw@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.r...
"- 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
On 24 Apr 2023, at 10:02, Alex Balashov abalashov@evaristesys.com wrote:
On Apr 24, 2023, at 2:46 AM, Henning Westerholt hw@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.r...
"- 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?
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 24.04.23 10:29, Olle E. Johansson wrote:
On 24 Apr 2023, at 10:02, Alex Balashov abalashov@evaristesys.com wrote:
On Apr 24, 2023, at 2:46 AM, Henning Westerholt hw@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.r...
"- 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?
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.
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
On 24 Apr 2023, at 16:17, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 24.04.23 10:29, Olle E. Johansson wrote:
On 24 Apr 2023, at 10:02, Alex Balashov abalashov@evaristesys.com wrote:
On Apr 24, 2023, at 2:46 AM, Henning Westerholt hw@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.r...
"- 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?
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.
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 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:
- Successfull INVITE/200OK/ACK with alaw only
- RTPengine setup and active
- Re-invite with video added
- RTP engine active with video
- 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
On 25 Apr 2023, at 14:04, Richard Fuchs rfuchs@sipwise.com wrote:
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:
- Successfull INVITE/200OK/ACK with alaw only
- RTPengine setup and active
- Re-invite with video added
- RTP engine active with video
- 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 🤡
It’s just code, right?
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
On 25/04/2023 10.59, [EXT] Olle E. Johansson wrote:
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.
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.
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
On 25 Apr 2023, at 18:00, Richard Fuchs rfuchs@sipwise.com wrote:
On 25/04/2023 10.59, [EXT] Olle E. Johansson wrote:
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.
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
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…
Thank you for the quick answers. And thank you for all your work on RTPengine!
/O
-
Alex Balashov -
Benoît Panizzon -
Daniel-Constantin Mierla -
Henning Westerholt -
Ihor Olkhovskyi -
Olle E. Johansson -
Patrick Karton -
Richard Fuchs