I am using version 1.8.2 I think? I can check when I get back in the office. I thought we had downloaded the latest stable not too long ago but guess not. Is updating easy (i.e., no database wipe out?).
Nick. On 3/22/13, Răzvan Crainea <[email protected]> wrote: > Hi, Nick! > > What version of OpenSIPS are you using? This has been introduced in 1.9. > > Best regards, > > Razvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 03/21/2013 05:19 PM, Nick Khamis wrote: >> Is it not possible to pass a var or avp as an argument to the >> ip_address parameter of rtpproxy_answer/offer: >> >> $var(privateIP) = "192.168.2.5"; >> $avp(privateIP) = $var(privateIP); >> >> if (has_body("application/sdp")) rtpproxy_offer("rc","$avp(privateIP)"); >> >> I am getting a socket error.... >> >> Thanks in Advance, >> >> Nick. >> >> On 3/20/13, Nick Khamis <[email protected]> wrote: >>> You beat me to it!!!! I was just going to post my solution!!!!! >>> >>> So, pretending that Sammy did not say that :). >>> >>> I first fixed no audio with the "r" flag. This got outgoing audio >>> going as it uses the IP address from c= in the SDP payload. Now I >>> still had the problem with incoming RTP stream. Seemed like it was >>> getting routed elsewhere because it was not entering our network (no >>> it was no the firewall). After tinkering with ie, and shedding a few >>> tears.... I was able to fix this issue using the c flag and pointing >>> to public ip, for replies going out of the network. >>> I hope this saves someone two days some day: >>> >>> >>> route[1] { >>> if (is_method("INVITE")) { >>> t_on_branch("1"); >>> t_on_reply("1"); >>> t_on_failure("1"); >>> >>> >>> if (has_body("application/sdp")) { >>> if (client_nat_test("3")) >>> rtpproxy_offer("rc","public ip"); >>> else rtpproxy_offer("rc","private ip"); >>> } >>> } >>> else if (is_method("BYE|CANCEL")) { >>> unforce_rtp_proxy(); >>> } >>> >>> if (!t_relay()) { >>> sl_reply_error(); >>> }; >>> exit; >>> } >>> onreply_route[1] { >>> xlog("incoming reply\n"); >>> if (has_body("application/sdp")) { >>> if (client_nat_test("3")) rtpproxy_answer("rc","public >>> ip"); >>> else rtpproxy_answer("rc","private ip"); >>> } >>> } >>> >>> >>> Sammy I know you went through this a while back, that is why I sent >>> you the private email. I hope it did not offend you in any way! >>> >>> Nick. >>> >>> On 3/20/13, SamyGo <[email protected]> wrote: >>>> Hi Nick, >>>> >>>> When I first hit the same issue where media was to be sent/received from >>>> a >>>> different IP other than signalling I used 'r' flag in the >>>> engage_rtpproxy() >>>> function. I don't think you are using this function rather using offer >>>> and >>>> answer functions which I'd say a manual approach. >>>> Tell me if using the 'r' flag in both offer and answer helps with these >>>> calls. >>>> Umm...and yeah also check with your media server not to directmedia with >>>> the carrier. >>>> >>>> Thanks >>>> Sammy >>>> On Mar 21, 2013 1:45 AM, "Nick Khamis" <[email protected]> wrote: >>>> >>>>> Hello Razvan, and Sammy, >>>>> >>>>> I really appreciate any help I can get in the matter. Not to sound >>>>> like a broken record, but when the SIP and RTP stream are coming from >>>>> the same source: >>>>> >>>>> U 2013/03/20 16:13:55.029233 69.147.236.82:5060 -> 192.168.2.5:5060 >>>>> >>>>> o=root 19098 19098 IN IP4 69.147.236.82. >>>>> c=IN IP4 69.147.236.82. >>>>> >>>>> RTP and RTCP stats are flowing as expected, and we have two way audio: >>>>> >>>>> INFO:remove_session: RTP stats: 751 in from callee, 730 in from >>>>> caller, 1481 relayed, 0 dropped >>>>> INFO:remove_session: RTCP stats: 1 in from callee, 0 in from caller, 1 >>>>> relayed, 0 dropped >>>>> >>>>> >>>>> It would seem that, the problem arises when the SIP and RTP streams >>>>> are coming from different sources: >>>>> >>>>> U 2013/03/20 16:27:36.758048 81.201.86.45:5060 -> 192.168.2.5:5060 >>>>> o=root 5539 5539 IN IP4 81.201.86.26. >>>>> c=IN IP4 81.201.86.26 >>>>> >>>>> RTPProxy reports that RTP traffic is flowing from the callee, but in >>>>> fact there is no audio both ways: >>>>> >>>>> INFO:remove_session: RTP stats: 148 in from callee, 0 in from caller, >>>>> 148 relayed, 0 dropped >>>>> INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0 >>>>> relayed, 0 dropped >>>>> >>>>> Commenting out the RTP stuff in OpenSIPS leads to one way outgoing >>>>> audio. Looking closer at the RTP proxy log I see that it's prefilling >>>>> the caller's address to the source of the SIP messages and not to the >>>>> source of the RTP stream: >>>>> >>>>> INFO:handle_command: pre-filling caller's address with >>>>> 81.201.86.45:10118 >>>>> >>>>> A trace on the RTP stream confirms this: >>>>> >>>>> 130.427203 192.168.2.100 -> 192.168.2.5 UDP 214 Source port: vtsas >>>>> Destination port: 9624 >>>>> 130.427338 192.168.2.5 -> 81.201.86.45 UDP 214 Source port: 30060 >>>>> Destination port: 17020 >>>>> 130.468931 192.168.2.100 -> 192.168.2.5 UDP 214 Source port: vtsas >>>>> Destination port: 9624 >>>>> 130.468985 192.168.2.5 -> 81.201.86.45 UDP 214 Source port: 30060 >>>>> Destination port: 17020 >>>>> >>>>> Thanks in Advance, >>>>> >>>>> Nick. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 3/19/13, Nick Khamis <[email protected]> wrote: >>>>>> Hello Razvan, >>>>>> >>>>>> I should have mentioned that we only experienced this issue with this >>>>>> particular DID provider. With others everything works perfectly. We >>>>>> suspect the issue is because the RTP stream is coming from a different >>>>>> source that of the SIP messages. So I think it's a matter of lining up >>>>>> rtpproxy_offer/answer parameters (i.e., co). >>>>>> >>>>>> Unfortunately, their service to our zone today is down. Will post >>>>>> detailed logs as soon as we can initiate some calls. >>>>>> >>>>>> Nick. >>>>>> >>>>>> On 3/19/13, Răzvan Crainea <[email protected]> wrote: >>>>>>> Hi, Nick! >>>>>>> >>>>>>> You said that you can see logs for RTPProxy. Can you set the debug >>>>>>> level >>>>>>> to DBUG and paste (preferably on pastebin) the logs of the session? >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Razvan Crainea >>>>>>> OpenSIPS Core Developer >>>>>>> http://www.opensips-solutions.com >>>>>>> >>>>>>> On 03/19/2013 03:52 PM, Nick Khamis wrote: >>>>>>>> I wanted to mention that the same setup works perfectly with VoIP.ms >>>>>>>> but not Voxbone. I think the problem is that the SIP messages and >>>>>>>> RTP >>>>>>>> stream for voxbone are coming from different sources. With other >>>>>>>> origination providers SIP and RTP streams came from the same source, >>>>>>>> so we never experienced a problem. >>>>>>>> >>>>>>>> We are currently looking into rtpproxy_orffer/answer parameters >>>>>>>> (i..e, >>>>>>>> "reico"...) to see if we can line things up nicely. >>>>>>>> >>>>>>>> Nichola. >>>>>>>> >>>>>>>> On 3/19/13, Nick Khamis <[email protected]> wrote: >>>>>>>>> RTPProxy does work behind NAT. It's mediaporxy that must be on a >>>>> public >>>>>>>>> ip. >>>>>>>>> >>>>>>>>> Thanks for your help. >>>>>>>>> >>>>>>>>> Nick. >>>>>>>>> >>>>>>>>> On 3/19/13, Muhammad Shahzad <[email protected]> wrote: >>>>>>>>>> If you are unfamiliar with rtp proxy and how it works, then it >>>>>>>>>> would >>>>>>>>>> be >>>>>>>>>> better for you to use engage_rtp_proxy rather then offer / answer >>>>>>>>>> model. >>>>>>>>>> Also RTP Proxy requires public IP address, its likely not to work >>>>>>>>>> on >>>>>>>>>> private subnets (unless you have all SIP entities on same LAN, in >>>>>>>>>> which >>>>>>>>>> case theoretically it should work but i have never tested it >>>>>>>>>> myself). >>>>>>>>>> >>>>>>>>>> Thank you. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Mar 18, 2013 at 4:18 PM, Nick Khamis <[email protected]> >>>>> wrote: >>>>>>>>>>> I am not sure if this is the correct place to post >>>>>>>>>>> OpenSIPS+RTPProxy >>>>>>>>>>> questions however, I tried to subscribing to the RTP proxy >>>>>>>>>>> mailing >>>>>>>>>>> list and never heard from them since. If it is ok to post RTP >>>>>>>>>>> proxy >>>>>>>>>>> related questions here.... I am trying to test OpenSIPS with RTP >>>>>>>>>>> proxy >>>>>>>>>>> with everything behind the same NAT box (i.e., 2 UAs, OpenSIPS, >>>>>>>>>>> RTPPoxy) just for testing. >>>>>>>>>>> >>>>>>>>>>> The code I am using is: >>>>>>>>>>> >>>>>>>>>>> route { >>>>>>>>>>> force_rport(); >>>>>>>>>>> } >>>>>>>>>>> route[1] { >>>>>>>>>>> if (is_method("INVITE")) { >>>>>>>>>>> t_on_branch("1"); >>>>>>>>>>> t_on_reply("1"); >>>>>>>>>>> t_on_failure("1"); >>>>>>>>>>> >>>>>>>>>>> if (has_body("application/sdp")) >>>>>>>>>>> rtpproxy_offer(); >>>>>>>>>>> } >>>>>>>>>>> else if (is_method("BYE|CANCEL")) { >>>>>>>>>>> unforce_rtp_proxy(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> if (!t_relay()) { >>>>>>>>>>> sl_reply_error(); >>>>>>>>>>> }; >>>>>>>>>>> exit; >>>>>>>>>>> } >>>>>>>>>>> onreply_route[1] { >>>>>>>>>>> if (has_body("application/sdp")) rtpproxy_answer(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> There is no way audio using RTP proxy, but audio is fine between >>>>>>>>>>> the >>>>>>>>>>> UA without including the RTP proxy related script. Looking at the >>>>> log >>>>>>>>>>> I found that RTP is prefilling the callers address twice, but not >>>>> the >>>>>>>>>>> callees address. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> INFO:main: rtpproxy started, pid 7287 >>>>>>>>>>> INFO:handle_command: new session >>>>>>>>>>> ae450168-538e-e211-8550-001b7700a65b@oakville, tag >>>>>>>>>>> d23f0168-538e-e211-8550-001b7700a65b;1 requested, type strong >>>>>>>>>>> INFO:handle_command: new session on a port 35010 created, tag >>>>>>>>>>> d23f0168-538e-e211-8550-001b7700a65b;1 >>>>>>>>>>> INFO:handle_command: pre-filling caller's address with >>>>>>>>>>> 192.168.2.101:5062 >>>>>>>>>>> INFO:handle_command: new session >>>>>>>>>>> ae450168-538e-e211-8550-001b7700a65b@oakville, tag >>>>>>>>>>> d23f0168-538e-e211-8550-001b7700a65b;2 requested, type strong >>>>>>>>>>> INFO:handle_command: new session on a port 22982 created, tag >>>>>>>>>>> d23f0168-538e-e211-8550-001b7700a65b;2 >>>>>>>>>>> INFO:handle_command: pre-filling caller's address with >>>>>>>>>>> 192.168.2.101:5064 >>>>>>>>>>> INFO:handle_delete: forcefully deleting session 1 on ports >>>>>>>>>>> 35010/0 >>>>>>>>>>> INFO:remove_session: RTP stats: 0 in from callee, 0 in from >>>>>>>>>>> caller, >>>>> 0 >>>>>>>>>>> relayed, 0 dropped >>>>>>>>>>> INFO:remove_session: RTCP stats: 0 in from callee, 0 in from >>>>>>>>>>> caller, >>>>>>>>>>> 0 >>>>>>>>>>> relayed, 0 dropped >>>>>>>>>>> INFO:remove_session: session on ports 35010/0 is cleaned up >>>>>>>>>>> INFO:handle_delete: forcefully deleting session 2 on ports >>>>>>>>>>> 22982/0 >>>>>>>>>>> INFO:remove_session: RTP stats: 0 in from callee, 0 in from >>>>>>>>>>> caller, >>>>> 0 >>>>>>>>>>> relayed, 0 dropped >>>>>>>>>>> INFO:remove_session: RTCP stats: 0 in from callee, 0 in from >>>>>>>>>>> caller, >>>>>>>>>>> 0 >>>>>>>>>>> relayed, 0 dropped >>>>>>>>>>> INFO:remove_session: session on ports 22982/0 is cleaned up >>>>>>>>>>> >>>>>>>>>>> Is it possible to test RTP relaying with everything on the same >>>>>>>>>>> network? >>>>>>>>>>> >>>>>>>>>>> Thanks in Advance, >>>>>>>>>>> >>>>>>>>>>> Nick. >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Users mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Mit freundlichen Grüßen >>>>>>>>>> Muhammad Shahzad >>>>>>>>>> ----------------------------------- >>>>>>>>>> CISCO Rich Media Communication Specialist (CRMCS) >>>>>>>>>> CISCO Certified Network Associate (CCNA) >>>>>>>>>> Cell: +49 176 99 83 10 85 >>>>>>>>>> MSN: [email protected] >>>>>>>>>> Email: [email protected] >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >> _______________________________________________ >> 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 > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
