[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?
> On 25 Apr 2023, at 18:00, Richard Fuchs 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 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?
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 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?
> On 25 Apr 2023, at 14:04, Richard Fuchs 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: >> >> 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 嵐 > 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 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?
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 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?
> On 24 Apr 2023, at 16:17, Daniel-Constantin Mierla wrote: > > > On 24.04.23 10:29, Olle E. Johansson wrote: >> >>> On 24 Apr 2023, at 10:02, Alex Balashov wrote: >>> >>> On Apr 24, 2023, at 2:46 AM, Henning Westerholt wrote: Hello, actually, this also documented in the kamailio modules readme: https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.rtpengine_manage "- 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 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?
On 24.04.23 10:29, Olle E. Johansson wrote: > >> On 24 Apr 2023, at 10:02, Alex Balashov wrote: >> >> >>> On Apr 24, 2023, at 2:46 AM, Henning Westerholt wrote: >>> >>> Hello, >>> >>> actually, this also documented in the kamailio modules readme: >>> >>> https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.rtpengine_manage >>> >>> "- 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 -- 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 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?
> On 24 Apr 2023, at 10:02, Alex Balashov wrote: > > >> On Apr 24, 2023, at 2:46 AM, Henning Westerholt wrote: >> >> Hello, >> >> actually, this also documented in the kamailio modules readme: >> >> https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.rtpengine_manage >> >> "- 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 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?
> On Apr 24, 2023, at 2:46 AM, Henning Westerholt wrote: > > Hello, > > actually, this also documented in the kamailio modules readme: > > https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.rtpengine_manage > > "- 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 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?
Hello,
actually, this also documented in the kamailio modules readme:
https://kamailio.org/docs/modules/5.5.x/modules/rtpengine.html#rtpengine.f.rtpengine_manage
"- If reply to INVITE with code >= 300 do rtpengine_delete()"
Cheers,
Henning
-Original Message-
From: Benoît Panizzon
Sent: Freitag, 21. April 2023 17:05
To: Ihor Olkhovskyi
Cc: Kamailio (SER) - Users Mailing List
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 PrattelnFax +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-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?
Hello,I dont think rtpengine_manage() does automatically rtpengine on 4xx.You have to explicitly do it. Bécasse rtpengine Can not decide if 4xx is for initial invite or reinvite failure.My advise use rtpengine_offer and rtpengine_answer and rtpengine_delete instead of rtpengine_manage.Le 21 avr. 2023 08:53, Benoît Panizzon 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-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[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 PrattelnFax +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-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: rtpengine module: Actions caused by rtpengine_manage() on reply-codes?
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/b65c19fa29976b59403433ed8a5de4b7eef41afc/src/modules/rtpengine/rtpengine.c#L3866 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 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 PrattelnFax +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-le...@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) __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
