[Bug]: Wrong SDP offer on sending a re-invite after putting call on hold.

[tuijldert]

Context

Putting a call on hold fails when the RFC2833 option is active on both linphone-android as well as desktop-version.

General information

Device: mobile

• OS: android
• Version of the App: 5.1.x
• Version of the SDK: ??

Device: desktop

• OS: windows
• Version of the App: 5.0.x
• Version of the SDK: ??

Expected behaviour

When setting the call on hold, the already agreed-upon mapping should be used on the SDP offer within the re-INVITE.

To Reproduce

1. Configure linphone to enable rfc2833 and codecs pcma and opus.
2. Call the linphone with a mapping of telephone-event/8000 and -/48000 with a different rptmapping from 101 and 97.
3. Answer call
4. put call on hold
5. on android: call cannot be put on hold
   on desktop: call appears to be put on hold but cannot be resumed.

Additional context

Please find attached a network capture of the relevant SIP exchange.
Note that the initial dialog agrees upon rtpmaps of both 101 and 115 for the respective telephone-events.
Note also the re-invite offer in packet 6, where telephone-events are shuffled and mapped to 97 and 101 respectively.
It is especially the change of mapping on 101 from telephone-event/8000 to telephone-event/48000 that violates
RFC3264 which states:

However, in the
case of RTP, the mapping from a particular dynamic payload type
number to a particular codec within that media stream MUST NOT change
for the duration of a session. For example, if A generates an offer
with G.711 assigned to dynamic payload type number 46, payload type
number 46 MUST refer to G.711 from that point forward in any offers
or answers for that media stream within the session.

and

The mappings need to remain fixed for the duration of the session
because of the loose synchronization between signaling exchanges
of SDP and the media stream.

hence the resulting answer of 488 Not Acceptable Here.

SDK logs URL

LinphoneReinviteSnafu.pcapng.gz

[tuijldert]

Addendum:
Current workaround is to configure SIP INFO iso. RFC2833, hence impact of the issue is low.