RTPEngine invoked multiple times causes incorect SDP in last 200 OK

[kristina258]

Hi,

during a call, when RTPengine is invoked multiple times, the final 200 OK response, which contains the SDP does not include any codecs. This results in audio issues, as no audio codecs are available for negotiation and use. In the RTPengine log, when the last RTPengine call is made, there is a log entry stating "Not adding stray answer codec PCMA/8000 (8)." I think this log message indicates that the PCMA codec is not being included in the SDP of the final 200 OK response.

RTPEngine version: Version: 11.2.1.4+0~mr11.2.1.4 git-mr11.2.1-1d93d9b4

---

Our call trace: CarrierA -> Kamailio+RTPENGINE -> ..... -> Kamailio+RTPENGINE -> CarrierB

INVITEs

---

INVITE: CarrierA -> Kamailio+RTPENGINE

m=audio 20964 RTP/AVP 8 18 110
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:110 telephone-event/8000
a=ptime:20
a=3gOoBTC

---

RTPENGINE is invoked with following parameters:

[control] Dump for 'offer' from 1.2.3.4:57451: { "supports": [ "load limit" ], "sdp": "v=0
May 31 13:13:13 rtpengine2 rtpengine[768]: ", "ICE": "remove", "direction": [ "public", "internal_voice_network" ], "flags": [ "trust-address" ], "replace": [ "origin", "session-connection" ], "codec": { "strip": [ "all" ], "except": [ "PCMA", "telephone-event" ], "transcode": [ "OPUS" ] }, "rtcp-mux": [ "demux" ], "call-id": "d241db67-af69-46ca-b3f2-3ae2d6df8b85", "received-from": [ "IP4", "1.2.3.7" ], "from-tag": "SaU99KpKHKFvp", "command": "offer" }

INVITE: Kamailio+RTPENGINE -> ...... -> Kamailio+RTPENGINE (SDP is correctly modified)

m=audio 44606 RTP/AVP 8 96 97 110
a=3gOoBTC
a=rtpmap:8 PCMA/8000
a=rtpmap:96 OPUS/48000/2
a=rtpmap:97 telephone-event/48000
a=fmtp:97 0-15
a=rtpmap:110 telephone-event/8000
a=sendrecv
a=rtcp:44607
a=ptime:20

---

RTPENGINE is invoked with following parameters:

[control] Dump for 'offer' from 1.2.3.5:44685: { "supports": [ "load limit" ], "sdp": "v=0
May 31 13:13:13 rtpengine2 rtpengine[768]: ", "ICE": "remove", "direction": [ "internal_voice_network", "public" ], "flags": [ "trust-address" ], "replace": [ "origin", "session-connection" ], "codec": { "mask": [ "all" ], "except": [ "telephone-event" ], "transcode": [ "PCMU", "PCMA" ] }, "rtcp-mux": [ "demux" ], "call-id": "d241db67-af69-46ca-b3f2-3ae2d6df8b85", "received-from": [ "IP4", "1.2.3.8" ], "from-tag": "SaU99KpKHKFvp", "command": "offer" }

INVITE: Kamailio+RTPENGINE -> CarrierB (SDP is correctly modified)

m=audio 50102 RTP/AVP 0 8 110
a=3gOoBTC
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:110 telephone-event/8000
a=sendrecv
a=rtcp:50103
a=ptime:20

---

200 OKs

---

200 OK CarrierB -> Kamailio+RTPENGINE

m=audio 26848 RTP/AVP 0 110
a=rtpmap:0 PCMU/8000
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=silenceSupp:off - - - -
a=ptime:20

---

RTPENGINE is invoked with following parameters:

[control] Dump for 'answer' from 1.2.3.5:55824: { "supports": [ "load limit" ], "sdp": "v=0
May 31 13:13:14 rtpengine2 rtpengine[768]: ", "ICE": "remove", "direction": [ "public", "internal_voice_network" ], "flags": [ "trust-address" ], "replace": [ "origin", "session-connection" ], "codec": { "mask": [ "all" ], "except": [ "telephone-event" ], "transcode": [ "PCMU", "PCMA" ] }, "rtcp-mux": [ "demux" ], "call-id": "d241db67-af69-46ca-b3f2-3ae2d6df8b85", "received-from": [ "IP4", "1.2.3.7" ], "from-tag": "SaU99KpKHKFvp", "to-tag": "tKm2BF7pev5ej", "command": "answer" }

200 OK Kamailio+RTPENGINE -> ..... -> Kamailio+RTPENGINE (SDP is correctly modified)

m=audio 44626 RTP/AVP 8 110
a=silenceSupp:off - - - -
a=rtpmap:8 PCMA/8000
a=rtpmap:110 telephone-event/8000
a=sendrecv
a=rtcp:44627
a=ptime:20

---

RTPENGINE is invoked 4th time with following parameters:

[control] Dump for 'answer' from 1.2.3.4:57451: { "supports": [ "load limit" ], "sdp": "v=0
May 31 13:13:14 rtpengine2 rtpengine[768]: ", "ICE": "remove", "direction": [ "internal_voice_network", "public" ], "flags": [ "trust-address" ], "replace": [ "origin", "session-connection" ], "codec": { "strip": [ "all" ], "except": [ "PCMA", "telephone-event" ], "transcode": [ "OPUS" ] }, "rtcp-mux": [ "demux" ], "call-id": "d241db67-af69-46ca-b3f2-3ae2d6df8b85", "received-from": [ "IP4", "1.2.3.6" ], "from-tag": "SaU99KpKHKFvp", "to-tag": "tKm2BF7pev5ej", "command": "answer" }

200 OK Kamailio+RTPENGINE -> CarrierA (SDP is incorrect and missing PCMA and OPUS codec.)

m=audio 50082 RTP/AVP 110
a=silenceSupp:off - - - -
a=rtpmap:110 telephone-event/8000
a=sendrecv
a=rtcp:50083
a=ptime:20

Log from rtpengine:

[codec] Updating codecs for answerer tKm2BF7pev5ej #1
[codec] Not adding stray answer codec PCMA/8000 (8)
[codec] Adding codec telephone-event/8000 (110)
[codec] Setting up codec handlers for tKm2BF7pev5ej #1 -> SaU99KpKHKFvp #1
[codec] Default sink codec is PCMA/8000
[codec] Checking receiver codec telephone-event/8000/1 (110)
[codec] Sink codec is telephone-event/8000/1 (110)
[codec] Sink supports codec telephone-event/8000 for passthrough
[codec] Using passthrough handler for telephone-event/8000 with DTMF 110, CN -1
[codec] Codec answer for tKm2BF7pev5ej #1
[codec] Reverse codec for telephone-event/8000 (110) is telephone-event/8000 (110)
[codec] telephone-event/8000/1 payload type 110 already present, skip
[codec] Setting up codec handlers for SaU99KpKHKFvp #1 -> tKm2BF7pev5ej #1
[codec] Checking receiver codec telephone-event/8000/1 (110)
[codec] Sink codec is telephone-event/8000/1 (110)
[codec] Sink supports codec telephone-event/8000 for passthrough
[codec] Using passthrough handler for telephone-event/8000 with DTMF 110, CN -1
[codec] Updating supplemental codecs for SaU99KpKHKFvp #1
[codec] Updating supplemental codecs for tKm2BF7pev5ej #1
[codec] Setting up codec handlers for SaU99KpKHKFvp #1 -> tKm2BF7pev5ej #1
[codec] Checking receiver codec telephone-event/8000/1 (110)
[codec] Sink codec is telephone-event/8000/1 (110)
[codec] Sink supports codec telephone-event/8000 for passthrough
[codec] Using passthrough handler for telephone-event/8000 with DTMF 110, CN -1
[codec] Setting up codec handlers for tKm2BF7pev5ej #1 -> SaU99KpKHKFvp #1
[codec] Checking receiver codec telephone-event/8000/1 (110)
[codec] Sink codec is telephone-event/8000/1 (110)
[codec] Sink supports codec telephone-event/8000 for passthrough
[codec] Using passthrough handler for telephone-event/8000 with DTMF 110, CN -1
[control] Replying to 'answer' from 1.2.3.4:57451 (elapsed time 0.000299 sec)
[control] Response dump for 'answer' to 1.2.3.4:57451: { "sdp": "v=0
[core] Not switching from local socket 1.2.3.10:50102 to 1.2.3.9:44606 (not in list)
[core] Too many packets in UDP receive queue (more than 50), aborting loop. Dropped packets possible

I think the issue is the line with "[codec] Not adding stray answer codec PCMA/8000 (8)". Why is the message Not adding stray codec generated? And what does it do?

Could you please help me to find out what can cause the issue and how to fix it?

Thank you in advance.

[rfuchs]

This has been asked before and is a scenario not currently supported. Updating the media parameters in a session (e.g. the codecs) requires a full offer/answer exchange. Simply repeating an answer but with different parameters doesn't work.

The codec negotiation takes place during an answer and the list of codecs is flushed, leaving only accepted codecs. Another answer with different codecs is not able to restore codecs that have already been rejected previously.

[emvondo]

This has been asked before and is a scenario not currently supported. Updating the media parameters in a session (e.g. the codecs) requires a full offer/answer exchange. Simply repeating an answer but with different parameters doesn't work.

ok so for any answer there should one associated offer ?
can i send the same offer to rtpengine even if it does not change so that the answer correctly updates ?

[rfuchs]

This has been asked before and is a scenario not currently supported. Updating the media parameters in a session (e.g. the codecs) requires a full offer/answer exchange. Simply repeating an answer but with different parameters doesn't work.

ok so for any answer there should one associated offer ? can i send the same offer to rtpengine even if it does not change so that the answer correctly updates ?

Yes, that would be the current workaround. Store the last offer SDP somewhere, then replay the last offer and then process the new answer.

[emvondo]

This has been asked before and is a scenario not currently supported. Updating the media parameters in a session (e.g. the codecs) requires a full offer/answer exchange. Simply repeating an answer but with different parameters doesn't work.

ok so for any answer there should one associated offer ? can i send the same offer to rtpengine even if it does not change so that the answer correctly updates ?

Yes, that would be the current workaround. Store the last offer SDP somewhere, then replay the last offer and then process the new answer.

ok thanks will try it. another question by doing this (store last offer and replay it before answer) and if receive multiple to-tags for answer 180(tag1 & ip1 & port1) and after 200(tag2 & ip2 & port2) will rtpengine switch correctly to ip2:port2 ?

i already store the tag1 and reuse it for all sdp processing for that specific call. but in that rtpengine did not switch to switch to ip2:port2.

so is it related only to always make (and replay) 1 offer for every answer ? or maybe to the fact i'm using strict-source ? (no-rtcp-attribute asymmetric port-latching strict-source replace-origin replace-sdp-version replace-zero-address replace-session-connection ICE=remove)

are sdp args (like strict-source) sent to rtpengine all reset when offer-answer is complete ?

Thanks.

[rfuchs]

This has been asked before and is a scenario not currently supported. Updating the media parameters in a session (e.g. the codecs) requires a full offer/answer exchange. Simply repeating an answer but with different parameters doesn't work.

ok so for any answer there should one associated offer ? can i send the same offer to rtpengine even if it does not change so that the answer correctly updates ?

Yes, that would be the current workaround. Store the last offer SDP somewhere, then replay the last offer and then process the new answer.

ok thanks will try it. another question by doing this (store last offer and replay it before answer) and if receive multiple to-tags for answer 180(tag1 & ip1 & port1) and after 200(tag2 & ip2 & port2) will rtpengine switch correctly to ip2:port2 ?

This is a different scenario and not related to this issue. Use the mailing list for other/generic questions like this.