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
