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:
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