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
