25 Apr
2023
25 Apr
'23
8:04 a.m.
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