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