[OpenSIPS-Users] RTPProxy Support - Not prefilling callees address
Nick Khamis
symack at gmail.com
Wed Mar 20 23:30:28 CET 2013
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 <govoiper at gmail.com> 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" <symack at gmail.com> 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 <symack at gmail.com> 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 <razvan at opensips.org> 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 <symack at gmail.com> 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 <shaheryarkh at gmail.com> 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 <symack at gmail.com>
>> 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 at 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 at 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
>> >>>>>> Users at lists.opensips.org
>> >>>>>> 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: shari_786pk at hotmail.com
>> >>>>> Email: shaheryarkh at googlemail.com
>> >>>>>
>> >>> _______________________________________________
>> >>> Users mailing list
>> >>> Users at lists.opensips.org
>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >>
>> >>
>> >> _______________________________________________
>> >> Users mailing list
>> >> Users at lists.opensips.org
>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >>
>> >
>>
>
More information about the Users
mailing list