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