RTPengine dropping Codec in 200OK

[Lewis]

I am unsure if this is an issue or by design right now trying to find some details in RFC's but wanted to throw it out to the group.

I have a case where a SIP Phone is making a call to the PSTN and is given Early Media by the PSTN. At the point of answer there is a code change which RTPengine strips and it kills the call.

here is the flow

SIP Phone -> Kamailio Reg | FreeSWITCH | Kamailio Core -> PSTN

                        (---------------------  RTPengine --------------------------)

aLeg INVITE from SIP Phone G722, PCMA | bLeg INVITE to PSTN PCMA

(FreeSWITCH is controlling the 2 legs Codecs at this point which we are ok with being different at this stage)

183 SDP to SIP Phone G722 negotiated by SIP Phone Preference and FreeSWITCH settings
(Early Media is setup and working aLeg = G722 and bLeg = PCMA) again we are all ok with this at this point

At the point of answer at PSTN the 200OK is proxied all the way through with PCMA to the SIP Phone (FreeSWITCH is not interacting with it at all) but at the point of Kamailio Reg and RTPengine, RTPengine is dropping the PCMA Codec and sending a Codecless SDP to the Phone which kills the call..

183 SDP  from PSTN coming out of FreeSWITCH to Kamailio Reg
v=0
o=freeswitch-2 1700514562 1700514563 IN IP4  10.x.x.x
s=freeswitch-2
c=IN IP4  10.x.x.x
t=0 0
m=audio 43096 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=rtcp:43097 IN IP4  10.x.x.x

183 SDP from Kamailio Reg with RTPengine to SIP Phone
v=0
o= freeswitch-2  1700514562 1700514563 IN IP4  18.xxx.xxx.11
s= freeswitch-2
c=IN IP4  18.xxx.xxx.11
t=0 0
m=audio 10524 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=rtcp:10525
a=ptime:20

200OK SDP from PSTN coming out of FreeSWITCH to Kamailio Reg
v=0
o= freeswitch-2  1700514562 1700514566 IN IP4 10.x.x.x
s= freeswitch-2
c=IN IP4 10.x.x.x
t=0 0
m=audio 43096 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=rtcp:43097 IN IP4 x.x.x
a=ptime:20
a=sendrecv

200OK from Kamailio Reg with RTPengine to SIP Phone
v=0
o=freeswitch-2 1700514562 1700514564 IN IP4 18.xxx.xxx.11
s=freeswitch-2
c=IN IP4  18.xxx.xxx.11
t=0 0
m=audio 10524 RTP/AVP 101
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=rtcp:10525
a=ptime:20

I can negate this issue by preventing the SIP Phone offering G722 but that's not the requirements I either nee to look at FreeSWITCH (which i am doing) to change the 183SDP Codec or allow the 200OK Codec to be negotiated with the SIP Phone which supports it (if this is RFC compliant to change the codec in the 200OK which i honestly am not sure it is)

Any help is appreciated

[Johan De Clercq]

I am not too sure about your latest statement. 

You already have a codec, hence if you want to change it before the ack, you should use update. 

another simple solution is to send 200 OK without sdp. 

BR, Johan. 

Op di 21 nov 2023 om 10:29 schreef Lewis <lewishu...@live.co.uk>:

--
You received this message because you are subscribed to the Google Groups "rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/df55ccad-d9d1-4069-b3f3-0075996a84a7n%40googlegroups.com.

[Lewis]

Hi Johan

Thanks for the reply, Sorry if i am not being clear

Unfortunately at the moment this appears to be all out of our control and I am looking for a way to control this behavior. I am looking for way to control this in FreeSWITCH right now but I was wondering if there is a way for RTPengine to know that the Codec has change between 183SDP and 200OK, then instead of stripping it revert to the previously agreed codec G722. By stripping the Codec when the SIP Phone gets the 200OK it kills the call.

Regards
Lewis

[Lewis]

UPDATE: Just to note I have managed to work around this in FreeSWITCH and as it turns out bring in a few new learned improvements to our codec handling but the here case still stands, if this is a bug that changing the SDP between 183SDP and 200OK RTPengine appears to strip the codec in the 200OK 

Happy to help doing some debug work if needed.

RTPEngine Version -  10.4.1.3-1~bpo10+1

[Richard Fuchs]

On 21/11/2023 11.24, [EXT] Lewis wrote:

UPDATE: Just to note I have managed to work around this in FreeSWITCH and as it turns out bring in a few new learned improvements to our codec handling but the here case still stands, if this is a bug that changing the SDP between 183SDP and 200OK RTPengine appears to strip the codec in the 200OK 

Happy to help doing some debug work if needed.

RTPEngine Version -  10.4.1.3-1~bpo10+1

You'll have to post a debug log from rtpengine so that we can see what exactly has been signalled to rtpengine and with which options and what the SDPs looked like. Also not that 10.4 is not LTS and it would be wise to switch to 10.5 at least.

Cheers