[SR-Users] RTPEngine: rtpengine_manage(), Subsequent requests, Transcoding

[Richard Fuchs]

On 29/05/2019 06.57, Carsten Bock wrote:
> Hi,
>
> quick question:
> If understood it correctly in the past (and it worked for me quite 
> well this way), I can simply call rtpengine_manage() for subsequent 
> requests without adding any additional information (e.g. used 
> interfaces, RTP/SRTP translation or anything like that), as this 
> information is stored in the internal hash table of the RTPEngine 
> module during call setup and initial offer/answer.
>
> However, this does not seem to apply to the transcoding options. When 
> I just call "rtpengine_manage()" for a Re-INVITE of a transcoded call 
> (in my case AMR-WB to G722), the transcoding options are no longer 
> applied. The forwarded offer does not get the transcoded codecs added 
> (e.g. in my case G722 is not added to the list of AMR/AMR-WB from the 
> phone).
>
> Did I misunderstand something or is it a bug?
>
> My RTPEngine is still on 7.2, but I will double check with more recent 
> versions today or tomorrow. However, I also found no commit messages 
> relating to this.

It depends on your point of view whether you see this as a feature, a 
bug, or a missing feature. :) But yes, currently the codecs seen in an 
offer SDP passing through empty out the list of known codecs and 
populates it fresh, which requires the desired transcoding options to be 
given fresh also. The reason for this is that it's obviously possible 
for a client to start a codec renegotiation at any time, and that may 
result in a different codec pairing after a re-invite. So the preferred 
way to handle this is to detect it in your script and pass the 
appropriate options.

Cheers