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: [email protected] [mailto:[email protected]] On Behalf Of Razvan Crainea Sent: 22 June 2011 08:44 To: [email protected] 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 [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
