29 May
2019
29 May
'19
1:57 p.m.
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