OPUS to G729 Transcoding broken after SIP Re-INVITE (No SDP)

[adil-mafzool]

I am having transcoding issue with particular scenario when rtpengine is initially transcoding audio stream between opus and G729 but after SIP re-INVITE with NOSDP is initiated rtpengine transcoding is broken and it starts to send opus to the party which doesn't even support g729: -

SIP signalling and RTP streams info: -

 (webrtc gateway/janus) 10.219.36.155 --------------------> (kamailio/rtpengine)10.211.95.1 ----------------> (third party)10.211.72.1
Media IP:       10.219.36.155                                           10.211.95.2                                10.210.90.1     
   (OFFER) audio 34690 RTP/AVP                         (ANSWER) audio 18354 / (OFFER) audio 18338          (ANSWER)  audio 22728 with 
    RTP/AVP 111 9 8 110 126                            RTP/AVP 111 9 8 18 110 126 / 111 9 8 18 126 110 126     RTP/AVP 18 126
     RTP      <==========================OPUS========================>              =====================G729=================>
	                                         NO Issue with Transcoding initial call
     

	 
                                                                                                               Re-INVITE with NOSDP FROM
(webrtc gateway/janus) 10.219.36.156 <-------------------- (kamailio/rtpengine)10.211.95.1 <---------------- (third party)10.211.72.1
        NOSDP                                                      NOSDP                                         NOSDP
   (OFFER) audio 34690 RTP/AVP                            (ANSWER) audio 18354 / (OFFER) audio 18338          (ANSWER)  audio 14416
Media IP:  10.219.36.156                                          10.211.95.2  / 10.211.95.2                      10.210.72.111
    RTP/AVP 111 9 0 8 126 110                            RTP/AVP 111 9 8 110 126 126 / 18 111 9 8 126 110         RTP/AVP 18 126
	     RTP   <=======================OPUS============================>              =======================OPUS ???=============> 
		                                            Here! RTPEngine transcoding is broken with OPUS RTP stream being sent to Media IP: 10.210.72.111 where it doesn't even support it
		                                                                     <===============G729========================
					
    RTCP(No Issues)   <===================================================>             <==================================>

Wireshark call flow: -

rtpengine version: 9.5.7.1 custom running on the redhat
Linux xxx-xxxx-xxx-xxx-02.xxxxxxxxxx3.xxxxx 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Attached rtpengine log with loglevel 7
opus-g729-bad-transcod.log

Wireshark capture: -
opus-g729-transcode-bad.zip

Please can someone pointers me where can be the issue :) as the issue is always occurring: -

Second example call flow: -

[rfuchs]

Looks like this is from a modified code base? I don't think we've ever had a log line Forcing late offer

[adil-mafzool]

@rfuchs It is custom rtpengine version: 9.5.7.1 but the Force late offer change has been added from the previous custom release 9.0.1.4 code change is here: -

@@ +1415,17 @@@ void codec_handlers_update(struct call_

                pcm_dtmf_detect = 1;
  
+        if (flags && flags->opmode == OP_OFFER && flags->force_late_offer) {
+         ilog(LOG_DEBUG, "Forcing late offer");
+         MEDIA_CLEAR(sink,TRANSCODE);
+        }
+ 

Not sure it is cause of this issue as previous rtpengine version 9.0.1.4 trace
opus-g729-transcode-good-9.0.1.4.log
contains it too in similar way with issue not seen. My intention is to move newer rtpengine version: 9.5.7.1 which fixes other issues.

[adil-mafzool]

@rfuchs I have removed the code to add force late offer flag and re-run the test but it hasn't made any difference. The rtpengine log of that rtpengine version: 9.5.7.1 is attached
opus-g729-trancode-issue.log
for your guidance.

[rfuchs]

I would suggest to add the same codec/transcoding flags to the re-invite offer as are present in the original offer.

I would also suggest to upgrade to 10.5 as it has much improved codec negotiation logic.