Call drops due to payload type change mid-call

[Huw Carpenter]

Hi Richard,

I've been having an issue with dropped calls after a session timer reINVITE, I wonder if I might have found a bug?

The situation is as follows:
1. Receive offer (with a=sendonly) from PBX with codecs: 126 (telephone-event/8000) 0 (PCMU/8000) 8 (PCMA/8000) 9 (G722/8000)
2. Transcode offer to send to WebRTC client, codecs now: 96 (Opus/48000) 97 (telephone-event/48000)
3. WebRTC client sends answer (with a=recvonly) with codecs: 96 (Opus/48000) 97 (telephone-event/48000)
4. rtpengine transcodes answer, codecs sent to PBX: 0 (PCMU/8000) 126 (telephone-event/8000)
5. PBX sends no-SDP reINVITE.
6. WebRTC client responds (now with a=sendrecv) with codecs: 96 (Opus/48000) 97 (telephone-event/48000)
7. rtpengine again transcodes to send on to PBX, codecs: 0 (PCMU/8000) 8 (PCMA/8000) 9 (G722/8000) 96 (telephone-event/8000)
8. PBX sends answer (with a=sendrecv) with codecs: 0 (PCMU/8000) 96 (telephone-event/8000)
9. rtpengine transcodes, answer to WebRTC client has codecs: 96 (Opus/48000) 97 (telephone-event/48000)
10. PBX sends session timer reINVITE after a time, with offer containing codecs: 0 (PCMU/8000) 96 (telephone-event/8000)
11. rtpengine transcodes, codecs to WebRTC client: 97 (Opus/48000) 98 (telephone-event/48000)
(call flow diagram attached)

Step 11 results in the call dropping. WebRTC internals show the following error in setLocalDescriptionOFailure on the RTCPeerConnection:

"Failed to set local answer sdp: Failed to set local audio description recv parameters for m-section with mid='1'."

Looking at the SDPs, the issue seems to be that payload type 97 changes purposes during the call, i.e. it starts by denoting telephone-event/48000, but by step 11 it denotes Opus/48000. Section 8.3.2 of RFC 3264 seems to indicate this goes against spec:

"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"
 
To prove this was the issue causing the call to drop, I manually added an extra "telephone-event/8000", with payload type 126, to the SDP returned by the WebRTC client in step 6 of the flow above. This resulted in "telephone-event/8000" using payload type 126 (rather than 96) in all further SDPs on the PBX side of the call, which resulted in the session timer reINVITE offer going to the WebRTC client from rtpengine with the existing "96 97" payload types, rather than "97 98". Obviously this just a hack though.

Attached is an rtpengine log file from a failed run. I'm using version mr11.0.1.5, by the way.

Let me know if there's anything else you need.

Thanks!

[Richard Fuchs]

Looking at the log, it's likely because you're too aggressive with the
codec manipulations you're telling rtpengine to do. In particular you
can try adding the flag no-codec-renegotiation to your offer flags. That
should suppress any undesired change in codecs and payload types.

But I do agree that this should be handled better out of the box. It's
probably a matter of making sure that the telephone-event payload type
remains unchanged if it was present before, instead of generating a new one.

Cheers

[Huw Carpenter]

Hi Richard,

Thanks for the response. I tried adding the flag you mentioned, but it results in a core dump shortly after the call is established, which is reproducible every time (logs and core available at: https://drive.google.com/file/d/1GVTXR-3IWpU6FgNAAYtKIKNYjEBH9wyF/view?usp=sharing). Is it likely that I need more wholesale changes to my codec flags or should this just have worked when added to the flags I already set?

Thanks,
Huw

[Richard Fuchs]

Well, you definitely shouldn't get a core :)

With that fixed (patch to be submitted soon) it looks like adding that
flag still isn't enough to make things work, even though technically it
should be. I'll have to look into why that is.

Cheers