[OpenSIPS-Users] rtpproxy stream2uac using incorrect codec
chris at ghosttelecom.com
Wed Jun 22 15:13:55 CEST 2011
Would have thought this would cause issues as the caller list is only a
request and cannot be confirmed until the callee confirms what he wants
to use. Is there a specific reason why it is like this as most playback
would be after at least some form of negotiated codec is confirmed and I
believe rtpproxy won't actually perform a playback unless an
rtpproxy_answer has been triggered?
On a similar note how do I get re-invites with sdp to be updated with
the correct rtpproxy entries when forwarded?
From: users-bounces at lists.opensips.org
[mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea
Sent: 22 June 2011 08:44
To: users at lists.opensips.org
Subject: Re: [OpenSIPS-Users] rtpproxy stream2uac using incorrect codec
I am afraid RTPProxy doesn't use the negociated codec to send media to
For the caller it uses the codec list received in the Update command,
and for callee the one received in Lookup.
On 21.06.2011 18:48, Chris Martineau wrote:
Doing some further testing looking at debug on rtpproxy I see the
initial offer giving Uc8,0,101 as the codec list, I then see the answer
giving Lc0,101 as the codec list but when I see the P stream message it
says it is playing the relevant prompt but using codec 8 surely it
should be using the negotiated codec in the answer message?
Any help would be appreciated.
Users mailing list
Users at lists.opensips.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users