[OpenSIPS-Users] rtpproxy stream2uac using incorrect codec

[Chris Martineau]

Hi,

 

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?

 

Many thanks

 

Chris

 

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

 

Hello Chris,

I am afraid RTPProxy doesn't use the negociated codec to send media to
UAC.
For the caller it uses the codec list received in the Update command,
and for callee the one received in Lookup. 

Regards,



Razvan Crainea
OpenSIPS Developer


On 21.06.2011 18:48, Chris Martineau wrote: 

 

Hi,

 

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.

 

Regards

 

Chris

 

 
 
_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110622/c7b7f1d2/attachment.htm>