[OpenSIPS-Users] Inconsistent c= and o= using rtpproxy_offer and rtpproxy_answer

[Bogdan-Andrei Iancu]

Hi Nick,

Use also the "f" flag (to ignore the indication of another rtpp in the 
message) - Razvan made a point in spotting the "a=nortpproxy:yes" in the 
incoming 183 reply.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 30.06.2014 21:17, Nick Cameo wrote:
> Hello Bogdan, I am not sure what autobridging is however, this is our 
> architecture:
>
> SIP Server 192.168.2.20
> RTPProxy Server 192.168.2.5
> Outside IP (Changed for Security): 77.71.33.152
> Origination Carrier (Changed for Security): 333.444.555.666
> Termination Carrier (Changed for Security): 222.11.22.33
>
> We start RTPProxy using the following command:
>
> /usr/local/rtpproxy/bin/rtpproxy -s udp:192.168.2.5:7789 
> <http://192.168.2.5:7789> -l 192.168.2.5/77.71.33.152 
> <http://192.168.2.5/77.71.33.152> -m 8000 -M 65535 -u root root -F -d 
> INFO LOG_LOCAL0
>
> RTPProxy Related Script in OpenSIPS Configuration:
>
> modparam("rtpproxy", "rtpproxy_sock", "udp:192.168.2.5:7789 
> <http://192.168.2.5:7789>")
>
> branch_route[1]
>         xlog("L_INFO","New Branch For: $ru at IP: $si\n");
>         if(has_body("application/sdp")) 
> rtpproxy_offer("roc","77.71.33.152");
>
> onreply_route[1]
>         xlog("L_INFO","Incoming Reply Route: From=$fu, To=$tu, RU=$ru, 
> CI=$ci IP=$si\n");
>         if(has_body("application/sdp")) 
> rtpproxy_answer("roc","192.168.2.5");
>
>
> I have attached three documents which contain the related slice
> for the problematic call in question:
>
> [i] SIP Trace
> [ii] RTP Trace
> [iii] RTP Proxy log
>
> Not on [iii], as you know there are two sessions per call. The first 
> has packets relayed from both
> caller and callee for the inbound part. The second session (ie, 
> outbound) has 0 packets relayed
> because the firewall is burning the packets both ways.
>
> Not to sound redundant, this is one of the very few cases where we 
> experience such problems.
> All other calls work as expected under the same environment.
>
> Thanks in Advance,
>
> Nick.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140701/b98afaf7/attachment.htm>