Sammy,
I am going to try and replace rtpproxy_offer/rtpproxy_answer with
rtpproxy_manage.
I have compared 183/200 messages on calls that have failed against calls
that are good, and the only difference is that it doesn't correctly
rewrite the SDP IP addresses (which is what I would expect since the
call to rtpproxy_answer failed).
I think the next thing to do is to turn on rtpproxy debug logs, but I
was trying to avoid this since it is a production environment and I
can't seem to replicate the issue in my development environment.
Thanks a lot for your help, I truly appreciate your time!
Seth
On 10/29/2012 1:54 AM, SamyGo wrote:
Hi,
Since this is working for you so I won't ask you to use
rtpproxy_manage function which is much easier to use. Anyway, Just
curious to know if you've any sample of 183/200 where rtpproxy failed,
corresponding rtpproxy debug logs and also a sample of 183/200 packet
to compare any differences.
Thanks,
Sammy
On Sat, Oct 27, 2012 at 1:54 AM, Seth Schultz
<[email protected] <mailto:[email protected]>> wrote:
Hello,
I am having an issue where rtpproxy_answer is failing in my
onreply_route block when processing 183 or 200 packets (snippet
below). This only happens on about 1% of the total call volume.
if (!rtpproxy_answer("eior"))
{
xlog("L_ERR", "UNABLE TO NEGOTIATE MEDIA");
}
1. How can I determine what is causing rtpproxy_answer to fail?
2. In what circumstances should I expect rtpproxy_answer to fail?
3. What action should I take if this happens?
Thank you very much for your time,
Seth
_______________________________________________
Users mailing list
[email protected] <mailto:[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
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
