Re: [OpenSIPS-Users] One way audio over 4g
Hi, Mark! Are you doing any RTP bridging, using RTPProxy, Media Proxy or RTPEngine? If not, perhaps you should. Also, if you need more help, you have to give us more information about what is the actual issue. A PCAP, or a SIP capture is a good start for that. Best regards, Răzva On 4/1/19 2:55 AM, Mark Thomas wrote: Weirdest thing. Everything is working fine over wifi. NAT traversal has been working fantastic, but I'm at a loss as far as what's going on when using 4g. I know that getting it to work is possible. It works fine connecting to signalwire and they use Kamailio on the front end. I really want to narrow down what's going on here. I could really use some insight here. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com Meet the OpenSIPS team at the next OpenSIPS Summit: https://www.opensips.org/events ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] One way audio over 4g
Weirdest thing. Everything is working fine over wifi. NAT traversal has been working fantastic, but I'm at a loss as far as what's going on when using 4g. I know that getting it to work is possible. It works fine connecting to signalwire and they use Kamailio on the front end. I really want to narrow down what's going on here. I could really use some insight here. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] One way audio problem
Hello All, I have configured opensips.cfg file and able call extensions of asterisk via opensips+rtpproxy. Now problem is that the solution is not stable. Sometimes it sends two way audio and sometimes single side audio problem. I can not identify what is problem with the solution. It working for a call and after sometimes it has single side audio problem. *Single side audio log* rtpproxy[3082]: INFO:handle_delete: forcefully deleting session 1 on ports 35006/35008 rtpproxy[3082]: INFO:remove_session: RTP stats: 0 in from callee, 8466 in from caller, 8466 relayed, 0 dropped rtpproxy[3082]: INFO:remove_session: RTCP stats: 32 in from callee, 36 in from caller, 68 relayed, 0 dropped rtpproxy[3082]: INFO:remove_session: session on ports 35006/35008 is cleaned up rtpproxy[3082]: INFO:remove_session: RTCP stats: 32 in from callee, 36 in from caller, 68 relayed, 0 dropped rtpproxy[3082]: INFO:remove_session: session on ports 35006/35008 is cleaned up opensips[11877]: ACC: transaction answered: timestamp=1403099904;method=BYE;from_tag=-UCwMHAsR;to_tag=gpclohfolgwgooy2.i;call_id=aJU-wli5bR;code=200;reason=OK *Two Way Audio log* rtpproxy[3082]: INFO:handle_delete: forcefully deleting session 1 on ports 35016/35010 rtpproxy[3082]: INFO:remove_session: RTP stats: 2251 in from callee, 2364 in from caller, 4615 relayed, 0 dropped rtpproxy[3082]: INFO:remove_session: RTCP stats: 9 in from callee, 12 in from caller, 21 relayed, 0 dropped rtpproxy[3082]: INFO:remove_session: session on ports 35016/35010 is cleaned up rtpproxy[3082]: INFO:remove_session: RTP stats: 2251 in from callee, 2364 in from caller, 4615 relayed, 0 dropped rtpproxy[3082]: INFO:remove_session: RTCP stats: 9 in from callee, 12 in from caller, 21 relayed, 0 dropped rtpproxy[3082]: INFO:remove_session: session on ports 35016/35010 is cleaned up rtpproxy[3082]: INFO:handle_command: delete request failed: session PwN15Vi6mz, tags LFUZbv7xG/fozygygpzem75cyd.i not found What is wrong with this? It sends audio two way and suddenly on second call one way audio problem occurs. Please help to resolve the issue. I am using *rtpproxy_offer(corsw); *in onreply_route[] function. -- Kind regards, Kaushik Parmar ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] one way audio in voip clients
Hi, So you are saying that all involved entities (caller, callee, opensips) are sitting in same network where direct IP communication between all parties is possible ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 05/06/2013 08:05 AM, sermj 2012 wrote: Sir, I am not using any firewall in our network but i am using NAT. But by disabling NAT also i didn't observe any change in connection. please advice On Sun, May 5, 2013 at 4:27 PM, Bogdan-Andrei Iancu bog...@opensips.org mailto:bog...@opensips.org wrote: Hello, Are any of your end points registering from behind a NAT (in relation to OpenSIPS) ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 05/04/2013 02:18 PM, sermj 2012 wrote: Iam new to opensips.i have installed successfully opensips on my pc. i have registered two voip clients. but only one way audio is working. please help me from this issue. ___ Users mailing list Users@lists.opensips.org mailto:Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] one way audio in voip clients
Can you please describe your network. What are the ip addresses of the OpenSIPS server, client A and client B. Further, can you provide a sip capture using ngrep (http://wiki.freeswitch.org/wiki/Packet_Capture) for a given call. I too am new to OpenSIPS, however this book (Goncalves F.E. - Building Telephony Systems with OpenSIPS 1.6) available free online brought me up to par within a week. It's based on 1.6 and a lot has changed with the latest stable, but the core concept still remains. Kind Regards, Nick. On 5/9/13, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi, So you are saying that all involved entities (caller, callee, opensips) are sitting in same network where direct IP communication between all parties is possible ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 05/06/2013 08:05 AM, sermj 2012 wrote: Sir, I am not using any firewall in our network but i am using NAT. But by disabling NAT also i didn't observe any change in connection. please advice On Sun, May 5, 2013 at 4:27 PM, Bogdan-Andrei Iancu bog...@opensips.org mailto:bog...@opensips.org wrote: Hello, Are any of your end points registering from behind a NAT (in relation to OpenSIPS) ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 05/04/2013 02:18 PM, sermj 2012 wrote: Iam new to opensips.i have installed successfully opensips on my pc. i have registered two voip clients. but only one way audio is working. please help me from this issue. ___ Users mailing list Users@lists.opensips.org mailto:Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] one way audio in voip clients
Sorry for the top post. Google client from hell... ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] one way audio problem
i configured and installed opensips successfully,i have registerd two clients:- 6005 :- 192.168.2.48 6006:- 192.168.2.50 i can hear only one way audio.iam using wifi standalone router to communicate with clients.i have searched in the blogs to slove the problem. by seeing the blogs i came to know that rtptproxy would slove problem. i have integrated opensips with rtpproxy module successfully, but still the problem is not sloved. iam attaching the sip trace file and opensips.cfg file. please help me from this issue. Thank you Nandini opensips.cfg Description: Binary data sip Description: Binary data ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] one way audio problem
Hi Nandini, You actually need to turn on the nat_traversal module I guess, will pass you the parameters if I get time to do so. --Aamir --- Sent from My BlackBerry --- -Original Message- From: sermj 2012 sermj2...@gmail.com Sender: users-boun...@lists.opensips.org Date: Tue, 7 May 2013 13:49:04 To: users@lists.opensips.org Reply-To: OpenSIPS users mailling list users@lists.opensips.org Subject: [OpenSIPS-Users] one way audio problem ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] one way audio problem
Hi Nandini,
The parameters and modules that you need to turn ON in your opensips.cfg file:
loadmodule nat_traversal.so
The above line load the module and the given below paragraph will set to test
the parameters.
route[nat_check] {
if (client_nat_test(3)) {
force_rport();
fix_contact();
nat_keepalive();
}
}
Everytime you route a call first test the calls through the route(nat_check)
which will fix all the NAT handling parameters.
For e.g. if you are gonna route INVITE request then you need to do it like this:
if(is_method(INVITE)) {
route(invite_requests);
exit;
}
route[invite_requests] {
route(nat_check);
if(!lookup(location)) {
sl_send_reply(404, User Not registered);
exit;
}
t_on_reply(user_reply);
t_relay();
exit;
}
Its just an example that how I do it and always you can explore things and read
the modules provided by OpenSIPS and upgrade yourself to use this server in all
possible cases.
Regards,
Aamir Chougule
Cell: 09167989111
From: Aamir aamir_...@yahoo.com
To: OpenSIPS users mailling list users@lists.opensips.org
Sent: Tuesday, 7 May 2013 1:58 PM
Subject: Re: [OpenSIPS-Users] one way audio problem
Hi Nandini,
You actually need to turn on the nat_traversal module I guess, will pass you
the parameters if I get time to do so.
--Aamir
--- Sent from My BlackBerry ---
-Original Message-
From: sermj 2012 sermj2...@gmail.com
Sender: users-boun...@lists.opensips.org
Date: Tue, 7 May 2013 13:49:04
To: users@lists.opensips.org
Reply-To: OpenSIPS users mailling list users@lists.opensips.org
Subject: [OpenSIPS-Users] one way audio problem
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] one way audio problem
Thanku very much for your prompt response,
iam new to opensips, please tell me where to add these lines in opensips.cfg
route[nat_check] {
if (client_nat_test(3)) {
force_rport();
fix_contact();
nat_keepalive();
}
}
The above lines i have added in opensips.cfg under Routing logic,
when i start opensips server,iam getting errors,
please help me.
Nandini
On Tue, May 7, 2013 at 2:30 PM, aamir chougule aamir_...@yahoo.com wrote:
Hi Nandini,
The parameters and modules that you need to turn ON in your opensips.cfg
file:
loadmodule nat_traversal.so
The above line load the module and the given below paragraph will set to
test the parameters.
route[nat_check] {
if (client_nat_test(3)) {
force_rport();
fix_contact();
nat_keepalive();
}
}
Everytime you route a call first test the calls through the
route(nat_check) which will fix all the NAT handling parameters.
For e.g. if you are gonna route INVITE request then you need to do it like
this:
if(is_method(INVITE)) {
route(invite_requests);
exit;
}
route[invite_requests] {
route(nat_check);
if(!lookup(location)) {
sl_send_reply(404, User Not registered);
exit;
}
t_on_reply(user_reply);
t_relay();
exit;
}
Its just an example that how I do it and always you can explore things and
read the modules provided by OpenSIPS and upgrade yourself to use this
server in all possible cases.
Regards,
Aamir Chougule
Cell: 09167989111
--
*From:* Aamir aamir_...@yahoo.com
*To:* OpenSIPS users mailling list users@lists.opensips.org
*Sent:* Tuesday, 7 May 2013 1:58 PM
*Subject:* Re: [OpenSIPS-Users] one way audio problem
Hi Nandini,
You actually need to turn on the nat_traversal module I guess, will pass
you the parameters if I get time to do so.
--Aamir
--- Sent from My BlackBerry ---
-Original Message-
From: sermj 2012 sermj2...@gmail.com
Sender: users-boun...@lists.opensips.org
Date: Tue, 7 May 2013 13:49:04
To: users@lists.opensips.org
Reply-To: OpenSIPS users mailling list users@lists.opensips.org
Subject: [OpenSIPS-Users] one way audio problem
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] one way audio problem
It should not be under main route block, just place it outside main route block.
For e.g.
route {
...
}
Place it here...
Or else paste your config file here.
--Aamir
--- Sent from My BlackBerry ---
-Original Message-
From: sermj 2012 sermj2...@gmail.com
Date: Tue, 7 May 2013 18:01:45
To: aamir chouguleaamir_...@yahoo.com; OpenSIPS users mailling
listusers@lists.opensips.org
Subject: Re: [OpenSIPS-Users] one way audio problem
Thanku very much for your prompt response,
iam new to opensips, please tell me where to add these lines in opensips.cfg
route[nat_check] {
if (client_nat_test(3)) {
force_rport();
fix_contact();
nat_keepalive();
}
}
The above lines i have added in opensips.cfg under Routing logic,
when i start opensips server,iam getting errors,
please help me.
Nandini
On Tue, May 7, 2013 at 2:30 PM, aamir chougule aamir_...@yahoo.com wrote:
Hi Nandini,
The parameters and modules that you need to turn ON in your opensips.cfg
file:
loadmodule nat_traversal.so
The above line load the module and the given below paragraph will set to
test the parameters.
route[nat_check] {
if (client_nat_test(3)) {
force_rport();
fix_contact();
nat_keepalive();
}
}
Everytime you route a call first test the calls through the
route(nat_check) which will fix all the NAT handling parameters.
For e.g. if you are gonna route INVITE request then you need to do it like
this:
if(is_method(INVITE)) {
route(invite_requests);
exit;
}
route[invite_requests] {
route(nat_check);
if(!lookup(location)) {
sl_send_reply(404, User Not registered);
exit;
}
t_on_reply(user_reply);
t_relay();
exit;
}
Its just an example that how I do it and always you can explore things and
read the modules provided by OpenSIPS and upgrade yourself to use this
server in all possible cases.
Regards,
Aamir Chougule
Cell: 09167989111
--
*From:* Aamir aamir_...@yahoo.com
*To:* OpenSIPS users mailling list users@lists.opensips.org
*Sent:* Tuesday, 7 May 2013 1:58 PM
*Subject:* Re: [OpenSIPS-Users] one way audio problem
Hi Nandini,
You actually need to turn on the nat_traversal module I guess, will pass
you the parameters if I get time to do so.
--Aamir
--- Sent from My BlackBerry ---
-Original Message-
From: sermj 2012 sermj2...@gmail.com
Sender: users-boun...@lists.opensips.org
Date: Tue, 7 May 2013 13:49:04
To: users@lists.opensips.org
Reply-To: OpenSIPS users mailling list users@lists.opensips.org
Subject: [OpenSIPS-Users] one way audio problem
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] one way audio in voip clients
Hello, Are any of your end points registering from behind a NAT (in relation to OpenSIPS) ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 05/04/2013 02:18 PM, sermj 2012 wrote: Iam new to opensips.i have installed successfully opensips on my pc. i have registered two voip clients. but only one way audio is working. please help me from this issue. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] one way audio in voip clients
Iam new to opensips.i have installed successfully opensips on my pc. i have registered two voip clients. but only one way audio is working. please help me from this issue. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] One-way audio problem with Opensips and Mediaproxy
Hello,
That is my first post here :)
I am playing around with NAT traversal and mediaproxy on opensips
1.6.3. (media-dispatcher 2.4.3, media-relay 2.4.3, python 2.6)
I've just encounterd a problem with my configuration that really worries me.
Here is my script:
# main request routing logic
route {
# -
# Sanity Check Section
# -
if (!mf_process_maxfwd_header(10)) {
sl_send_reply(483, Too Many Hops);
exit;
};
if (msg:len max_len) {
sl_send_reply(513, Message Overflow);
exit;
};
# -
# Record Route Section
# -
if (method==INVITE nat_uac_test(3)) {
record_route_preset(xx.yy.zz.vv:5060;nat=yes);
} else if (method!=REGISTER) {
record_route();
};
# -
# Call Tear Down Section
# -
if (method==BYE || method==CANCEL) {
end_media_session();
};
# -
# Loose Route Section
# -
if (loose_route()) {
if ((method==INVITE || method==REFER) !has_totag()) {
sl_send_reply(403, Forbidden);
exit;
};
if (method==INVITE) {
if (!proxy_authorize(,subscriber)) {
proxy_challenge(,0);
exit;
} else if (!db_check_from()) {
sl_send_reply(403, Use From=ID);
exit;
};
consume_credentials();
if (nat_uac_test(3) || search(^Route:.*;nat=yes)) {
setflag(6);
use_media_proxy();
};
};
route(1);
exit;
};
# -
# Call Type Processing Section
# -
if (uri!=myself) {
route(4);
route(1);
exit;
};
if (method==ACK) {
route(1);
exit;
} else if (method==CANCEL) {
route(1);
exit;
} else if (method==INVITE) {
route(3);
exit;
} else if (method==REGISTER) {
route(2);
exit;
};
lookup(aliases);
if (uri!=myself) {
route(4);
route(1);
exit;
};
if (!lookup(location)) {
sl_send_reply(404, User Not Found);
exit;
};
route(1);
}
route[1] {
# -
# Default Message Handler
# -
t_on_reply(1);
if (!t_relay()) {
if (method==INVITE || method==ACK) {
end_media_session();
};
sl_reply_error();
};
}
route[2] {
# -
# REGISTER Message Handler
#
sl_send_reply(100, Trying);
if (!search(^Contact:[ ]*\*) nat_uac_test(31)) {
setflag(6);
fix_nated_register();
force_rport();
};
if (!www_authorize(,subscriber)) {
www_challenge(,0);
exit;
};
if (!db_check_to()) {
sl_send_reply(401, Unauthorized);
exit;
};
consume_credentials();
if (!save(location)) {
sl_reply_error();
};
}
route[3] {
# -
# INVITE Message Handler
# -
if (nat_uac_test(3)) {
setflag(7);
force_rport();
fix_nated_contact();
};
if (!proxy_authorize(,subscriber)) {
proxy_challenge(,0);
exit;
} else if (!db_check_from()) {
sl_send_reply(403, Use From=ID);
exit;
};
consume_credentials();
lookup(aliases);
if (uri!=myself) {
route(4);
route(1);
exit;
};
if (!lookup(location)) {
sl_send_reply(404, User Not Found);
exit;
};
route(4);
route(1);
}
route[4] {
# -
# NAT Traversal Section
# -
if (isflagset(6) || isflagset(7)) {
if (!isflagset(8)) {
setflag(8);
use_media_proxy();
};
};
}
onreply_route[1] {
if ((isflagset(6) || isflagset(7)) (status=~(180)|(183)|2[0-9][0-9])) {
if (!search(^Content-Length:[ ]*0)) {
$avp(s:media_relay) = xx.yy.zz.vv;
use_media_proxy();
};
};
if (nat_uac_test(1)) {
fix_nated_contact();
};
}
Here is my call flow:
UA1(behindNAT)---Opensips,mediaproxy--Asterisk(publicip)UA2(behind
NAT)
If the call is originated from UA1 side, there is a both-ways audio.
The problem occurs in opposite scenario, if UA2 is calling UA1.
In db there are following entries:
| 101 | UA1number | NULL |
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Hmm, you are right, that wasn't the full syslog for that call. Investigating further I see that I get the following: Jan 11 22:28:07 sbc1 /usr/sbin/opensips[27792]: CRITICAL:dialog:log_next_state_dlg: bogus event 6 in state 2 for dlg 0x7f5e880692a0 [1305:480665684] with clid 'a27f94c89e3e13c410b392b13d753bdb84e00e2147f91b8-0266-6714' and tags 'e-13c4-10b392b-75e19db4-10b392b' '' This is right after the call has been established; the next event in the sip trace is at 22:53:40, the re-invite. According to a year old post by Bogdan ( http://www.mail-archive.com/users@lists.opensips.org/msg00700.html) this means that ACK is received before 200 OK. Here's the sip trace up to the point of the dialog error: 22:27:56.376925 Trunk - Proxy : INVITE 22:27:56.381153 Proxy - Trunk : 100 TRYING 22:27:56.381215 Proxy - UA___ : INVITE 22:27:56.437339 UA___ - Proxy : 100 TRYING 22:27:56.552454 UA___ - Proxy : 180 RINGING 22:27:56.552530 Proxy - Trunk : 180 RINGING 22:28:07.179499 UA___ - Proxy : 200 OK 22:28:07.182204 Proxy - Trunk : 200 OK 22:28:07.197002 Trunk - Proxy : ACK 22:28:07.197158 Proxy - UA___ : ACK Could this be the source of the problem? Best Regards, Magnus 2010/2/3 Saúl Ibarra Corretgé s...@ag-projects.com Hi, El 03/02/10 14:43, Magnus Burman escribió: Now I see what you're saying. I thought mediaproxy used the wrong port in the re-invite, while it is in fact not engaged at all and thus the original IP and port is sent on. That makes a lot of sense, thank you. According to the docs the engage_media_proxy should only be called once on the initial invite thou and after that use the dialog module to trace the dialog. Any suggestions as how to debug where it fails? I'm not getting any output in the syslog. You are correct, the by calling engage_mediaproxy the dialog module should take care. However, it's surprising that this only happens sometimes, so it's harder to debug :( Is the syslog you pasted in your earlier mail the only output you get for that call? Any warning from the dialog module? Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Hi Magnus, El 04/02/10 12:54, Magnus Burman escribió: Hmm, you are right, that wasn't the full syslog for that call. Investigating further I see that I get the following: Jan 11 22:28:07 sbc1 /usr/sbin/opensips[27792]: CRITICAL:dialog:log_next_state_dlg: bogus event 6 in state 2 for dlg 0x7f5e880692a0 [1305:480665684] with clid 'a27f94c89e3e13c410b392b13d753bdb84e00e2147f91b8-0266-6714' and tags 'e-13c4-10b392b-75e19db4-10b392b' '' This is right after the call has been established; the next event in the sip trace is at 22:53:40, the re-invite. According to a year old post by Bogdan (http://www.mail-archive.com/users@lists.opensips.org/msg00700.html) this means that ACK is received before 200 OK. Here's the sip trace up to the point of the dialog error: 22:27:56.376925 Trunk - Proxy : INVITE 22:27:56.381153 Proxy - Trunk : 100 TRYING 22:27:56.381215 Proxy - UA___ : INVITE 22:27:56.437339 UA___ - Proxy : 100 TRYING 22:27:56.552454 UA___ - Proxy : 180 RINGING 22:27:56.552530 Proxy - Trunk : 180 RINGING 22:28:07.179499 UA___ - Proxy : 200 OK 22:28:07.182204 Proxy - Trunk : 200 OK 22:28:07.197002 Trunk - Proxy : ACK 22:28:07.197158 Proxy - UA___ : ACK Could this be the source of the problem? Indeed. Whats happening is that the dialog state is 'broken' because OpenSIPS received the ACK before actually processing the 200OK (the 200OK is processed *after* it's sent). If you use engage_media_proxy function, MediaProxy will rely on the dialog state to internally call use_media_proxy function, but when that error happens MediaProxy doesn't act accordingly because the dialog state is broken. So, I see 3 possible solutions: 1- Use the manual functions (use_media_proxy and end_media_session) instead of engage_media_proxy. 2- Backport the dialog module fixes to your OpenSIPS version (revisions 5420 and 5422) 3- Upgrade OpenSIPS to a more recent version which includes the fix already. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Nice little utility, saves alot of time on typing. :-) Here's a pastbin with the correct format (ngrep-sip b) of the same call: http://pastebin.ca/1776903 Thanks, Magnus 2010/2/2 Iñaki Baz Castillo i...@aliax.net El Martes, 2 de Febrero de 2010, Magnus Burman escribió: I'll start capturing like that right away, less you want the pcap-file for that specific call? Since the problem only occurs sporadically and at re-invites (ie 20+ minutes into a call) it's a bit of a mess to track down calls that fit the criteria. But I'll get right on it for sure, thanks. Try this to filter the captured data: http://dev.sipdoc.net/projects/sip-stuff/wiki/Ngrep-SIP -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió: Nice little utility, saves alot of time on typing. :-) Here's a pastbin with the correct format (ngrep-sip b) of the same call: http://pastebin.ca/1776903 As you can see, the SDP in not modified by mediaproxy module for the re-INVITE and the 200 response for the re-INVITE. This means that you get one-way-audio as the caller is behind NAT. You should inspect why you are not calling mediaproxy functions when handling in-dialog INVITE and its responses. -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Hi Magnus, El 03/02/10 12:38, Magnus Burman escribió: Nice little utility, saves alot of time on typing. :-) Here's a pastbin with the correct format (ngrep-sip b) of the same call: http://pastebin.ca/1776903 Thanks, Magnus This looks as a configuration issue to me. Have a look at the reinvite, when it leaves the proxy (22.22.224.9 - 22.22.198.159) the IP in the SDP and Contact are not mangled (it's 11.11.0.144). You also need to check for NAT and mangle the SDP in that case. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
None of my users are behind NAT, they're all on public IPs (I control their
connection).
Sorry if it's a stupid question, but what do you mean with the SDP is not
modified by mediaproxy?
On line 276 in the re-invite (Opensips -- UA) the port used is different:
m=audio 40518 RTP/AVP 18 8 0 101'
The original invite (line 73) reads: m=audio 58928 RTP/AVP 18 8 0 101'
In the statistics dumped at the end, port says 58928.
This is my config in regards to mediaproxy. I included the loose_route above
as well, as this is all that comes before it in the route:
##Loose_route packets
if (loose_route()) {
# mark routing logic in request
append_hf(P-hint: rr-enforced\r\n);
if(method==BYE) {
setflag(1);
$avp(s:can_uri) = $ru;
}
route(1);
};
if (method==INVITE !has_totag()) {
if(avp_db_query(select 1 from subscriber_debug where username =
'$fU', $avp(s:debug))) {
# No media proxy if in debug
} else {
engage_media_proxy();
}
}
2010/2/3 Iñaki Baz Castillo i...@aliax.net
El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió:
Nice little utility, saves alot of time on typing. :-)
Here's a pastbin with the correct format (ngrep-sip b) of the same call:
http://pastebin.ca/1776903
As you can see, the SDP in not modified by mediaproxy module for the
re-INVITE
and the 200 response for the re-INVITE. This means that you get
one-way-audio
as the caller is behind NAT.
You should inspect why you are not calling mediaproxy functions when
handling
in-dialog INVITE and its responses.
--
Iñaki Baz Castillo i...@aliax.net
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió: None of my users are behind NAT, they're all on public IPs (I control their connection). It could occur that the gateway just allows RTP from certains IP's. Sorry if it's a stupid question, but what do you mean with the SDP is not modified by mediaproxy? Do you know how MediaProxy works by replacing the media IP in the SDP of INVITE and responses? Take a look to the first (initial) INVITE. The INVITE arrives to OpenSIPS with a media address XX.XX.XX.XX in the SDP, but when it leaves the proxy to go to the gateway the media is different because opensips has modified it to make it going through the MediaProxy server. But this doesn't occur for the re-INVITE as you can see in your trace. On line 276 in the re-invite (Opensips -- UA) the port used is different: m=audio 40518 RTP/AVP 18 8 0 101' The original invite (line 73) reads: m=audio 58928 RTP/AVP 18 8 0 101' Not just the port but also the SDP. And this occurs because the explained above: opensips is not replacing the ip:port in the SDP for the re-INVITE and its response. You should check why not. However I don't know mediaproxy module functions very well so I don't know what engage_mediaproxy should do. I just can tell you what is happening in the trace. -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Now I see what you're saying. I thought mediaproxy used the wrong port in the re-invite, while it is in fact not engaged at all and thus the original IP and port is sent on. That makes a lot of sense, thank you. According to the docs the engage_media_proxy should only be called once on the initial invite thou and after that use the dialog module to trace the dialog. Any suggestions as how to debug where it fails? I'm not getting any output in the syslog. Cheers, Magnus 2010/2/3 Iñaki Baz Castillo i...@aliax.net El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió: None of my users are behind NAT, they're all on public IPs (I control their connection). It could occur that the gateway just allows RTP from certains IP's. Sorry if it's a stupid question, but what do you mean with the SDP is not modified by mediaproxy? Do you know how MediaProxy works by replacing the media IP in the SDP of INVITE and responses? Take a look to the first (initial) INVITE. The INVITE arrives to OpenSIPS with a media address XX.XX.XX.XX in the SDP, but when it leaves the proxy to go to the gateway the media is different because opensips has modified it to make it going through the MediaProxy server. But this doesn't occur for the re-INVITE as you can see in your trace. On line 276 in the re-invite (Opensips -- UA) the port used is different: m=audio 40518 RTP/AVP 18 8 0 101' The original invite (line 73) reads: m=audio 58928 RTP/AVP 18 8 0 101' Not just the port but also the SDP. And this occurs because the explained above: opensips is not replacing the ip:port in the SDP for the re-INVITE and its response. You should check why not. However I don't know mediaproxy module functions very well so I don't know what engage_mediaproxy should do. I just can tell you what is happening in the trace. -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió: Now I see what you're saying. I thought mediaproxy used the wrong port in the re-invite, while it is in fact not engaged at all and thus the original IP and port is sent on. That makes a lot of sense, thank you. Yes, that's the problem. According to the docs the engage_media_proxy should only be called once on the initial invite thou and after that use the dialog module to trace the dialog. Any suggestions as how to debug where it fails? I'm not getting any output in the syslog. As I said I don't know mediaproxy module very well as I just used the old one (some years ago). -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Thank you for your help Iñaki, it's much appreciated. By asking my last question I was hoping someone else might chime in. :-) Best Regards, Magnus 2010/2/3 Iñaki Baz Castillo i...@aliax.net El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió: Now I see what you're saying. I thought mediaproxy used the wrong port in the re-invite, while it is in fact not engaged at all and thus the original IP and port is sent on. That makes a lot of sense, thank you. Yes, that's the problem. According to the docs the engage_media_proxy should only be called once on the initial invite thou and after that use the dialog module to trace the dialog. Any suggestions as how to debug where it fails? I'm not getting any output in the syslog. As I said I don't know mediaproxy module very well as I just used the old one (some years ago). -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Hi, El 03/02/10 14:43, Magnus Burman escribió: Now I see what you're saying. I thought mediaproxy used the wrong port in the re-invite, while it is in fact not engaged at all and thus the original IP and port is sent on. That makes a lot of sense, thank you. According to the docs the engage_media_proxy should only be called once on the initial invite thou and after that use the dialog module to trace the dialog. Any suggestions as how to debug where it fails? I'm not getting any output in the syslog. You are correct, the by calling engage_mediaproxy the dialog module should take care. However, it's surprising that this only happens sometimes, so it's harder to debug :( Is the syslog you pasted in your earlier mail the only output you get for that call? Any warning from the dialog module? Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Hi, El 02/02/10 11:54, Magnus Burman escribió: Hi guys, I've got a problem with sporadic one-way audio, using latest stable Opensips 1.4 and Mediaproxy 2. The problem occurs at re-invites, thou not every time. When it does happen, the media port is changed towards the callee. Example: First invite: INVITE Trunk:40518 -- Proxy:50358 INVITE Proxy:58928 -- UA:5206 Re-invite: INVITE Trunk:40518 -- Proxy:50358 INVITE Proxy:40518 -- UA:5206 Notice how the Proxy port on the UA side (callee local) changed to the same port that Trunk uses (caller remote). One way audio now occurs and naturally the call is soon hung up. Mediaproxy now dumps some useful statistics showing: 'callee_remote': 'UA:5206' 'caller_remote': 'TRUNK:40518' 'callee_local': 'PROXY:58928' 'caller_local': 'PROXY:50358' Notice here how the callee_local is the original port used. Where should I start looking to be able to solve this problem? Is it most likely my config, something weird with the re-invite or have I stumbled upon a bug? Thankful for every and all suggestions, as I lay sleepless at night thinking about this! :-P It would be nice to have a full SIP trace and the syslog output of MediaProxy to check if it's doing something wrong. Also, which function are you using for starting it? Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Hi,
I did a wireshark export, 2461 lines, so it's in the pastebin:
http://pastebin.ca/1775584
syslog below:
11.11.X.Y - Trunk subnet
22.22.X.Y - Proxy subnet
98400 - UA DID
X.voip.url.es - UA sip subscriber
Jan 11 22:28:07 sbc1 media-relay[4335]: debug: Got traffic information for
stream: (audio) 11.11.6.144:40518 (RTP: Unknown, RTCP: Unknown) -
22.22.224.9:50358 - 22.22.224.9:58928 - Unknown (RTP: 22.22.198.159:5206,
RTCP: Unknown)
Jan 11 22:28:07 sbc1 media-relay[4335]: debug: Got traffic information for
stream: (audio) 11.11.6.144:40518 (RTP: Unknown, RTCP: Unknown) -
22.22.224.9:50358 - 22.22.224.9:58928 - Unknown (RTP: 22.22.198.159:5206,
RTCP: 22.22.198.159:5207)
Jan 11 22:28:07 sbc1 media-relay[4335]: debug: Got initial answer from
callee for stream: (audio) 11.11.6.144:40518 (RTP: Unknown, RTCP: Unknown)
- 22.22.224.9:50358 - 22.22.224.9:58928 - 22.22.198.159:5206 (RTP:
22.22.198.159:5206, RTCP: 22.22.198.159:5207)
Jan 11 22:28:07 sbc1 media-relay[4335]: debug: Got traffic information for
stream: (audio) 11.11.6.144:40518 (RTP: 11.11.6.144:40518, RTCP: Unknown)
- 22.22.224.9:50358 - 22.22.224.9:58928 - 22.22.198.159:5206 (RTP:
22.22.198.159:5206, RTCP: 22.22.198.159:5207)
Jan 11 22:29:26 sbc1 media-relay[4335]: debug: Got traffic information for
stream: (audio) 11.11.6.144:40518 (RTP: 11.11.6.144:40518, RTCP: Unknown)
- 22.22.224.9:50358 - 22.22.224.9:58928 - 22.22.198.159:5206 (RTP:
22.22.198.159:5206, RTCP: 22.22.198.159:5207)
Jan 11 22:54:20 sbc1 media-dispatcher[4324]: debug: Got statistics:
{'from_tag': 'e-13c4-10b392b-75e19db4-10b392b', 'dialog_id':
'1305:480665684', 'start_time': 1263245287.181, 'timed_out': False,
'call_id': 'a27f94c89e3e13c410b392b13d753bdb84e00e2147f91b8-0266-6714',
'to_tag': 'ICF_197662497-514', 'streams': [{'status': 'closed',
'caller_codec': 'G711a', 'post_dial_delay': 10.76835417749,
'callee_codec': 'G711a', 'start_time': 0, 'caller_bytes': 15733000,
'callee_bytes': 15328600, 'caller_packets': 78665, 'end_time': 1573,
'callee_remote': '22.22.198.159:5206', 'caller_remote': '11.11.6.144:40518',
'media_type': 'audio', 'callee_local': '22.22.224.9:58928', 'timeout_wait':
0, 'caller_local': '22.22.224.9:50358', 'callee_packets': 76643}, {'status':
'rejected', 'caller_codec': 'Unknown', 'post_dial_delay': None,
'callee_codec': 'Unknown', 'start_time': 0, 'caller_bytes': 0,
'callee_bytes': 0, 'caller_packets': 0, 'end_time': 0, 'callee_remote':
'Unknown', 'caller_remote': 'Unknown', 'media_type': 'image',
'callee_local': '22.22.224.9:59676', 'timeout_wait': 0, 'caller_local': '
22.22.224.9:58930', 'callee_packets': 0}], 'duration': 1573, 'to_uri': '
984000...@22.22.224.9:5060', 'from_uri': '34963555...@11.11.0.144:5060',
'callee_ua': 'unknown agent', 'caller_ua': 'CS2000_NGSS/9.0'}
Cheers,
Magnus
2010/2/2 Saúl Ibarra Corretgé s...@ag-projects.com
Hi,
El 02/02/10 11:54, Magnus Burman escribió:
Hi guys,
I've got a problem with sporadic one-way audio, using latest stable
Opensips 1.4 and Mediaproxy 2.
The problem occurs at re-invites, thou not every time. When it does
happen, the media port is changed towards the callee. Example:
First invite:
INVITE Trunk:40518 -- Proxy:50358
INVITE Proxy:58928 -- UA:5206
Re-invite:
INVITE Trunk:40518 -- Proxy:50358
INVITE Proxy:40518 -- UA:5206
Notice how the Proxy port on the UA side (callee local) changed to the
same port that Trunk uses (caller remote).
One way audio now occurs and naturally the call is soon hung up.
Mediaproxy now dumps some useful statistics showing:
'callee_remote': 'UA:5206'
'caller_remote': 'TRUNK:40518'
'callee_local': 'PROXY:58928'
'caller_local': 'PROXY:50358'
Notice here how the callee_local is the original port used.
Where should I start looking to be able to solve this problem? Is it
most likely my config, something weird with the re-invite or have I
stumbled upon a bug?
Thankful for every and all suggestions, as I lay sleepless at night
thinking about this! :-P
It would be nice to have a full SIP trace and the syslog output of
MediaProxy to check if it's doing something wrong. Also, which function
are you using for starting it?
Regards,
--
Saúl Ibarra Corretgé
AG Projects
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
El 02/02/10 13:59, Magnus Burman escribió: Hi, I did a wireshark export, 2461 lines, so it's in the pastebin: http://pastebin.ca/1775584 It's really hard to follow a text wireshark cap, could you do a ngrep capture? ngrep -d any -W byline -T -P '' port 5060 -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
I'll start capturing like that right away, less you want the pcap-file for that specific call? Since the problem only occurs sporadically and at re-invites (ie 20+ minutes into a call) it's a bit of a mess to track down calls that fit the criteria. But I'll get right on it for sure, thanks. Cheers, Magnus 2010/2/2 Saúl Ibarra Corretgé s...@ag-projects.com El 02/02/10 13:59, Magnus Burman escribió: Hi, I did a wireshark export, 2461 lines, so it's in the pastebin: http://pastebin.ca/1775584 It's really hard to follow a text wireshark cap, could you do a ngrep capture? ngrep -d any -W byline -T -P '' port 5060 -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
El Martes, 2 de Febrero de 2010, Magnus Burman escribió: I'll start capturing like that right away, less you want the pcap-file for that specific call? Since the problem only occurs sporadically and at re-invites (ie 20+ minutes into a call) it's a bit of a mess to track down calls that fit the criteria. But I'll get right on it for sure, thanks. Try this to filter the captured data: http://dev.sipdoc.net/projects/sip-stuff/wiki/Ngrep-SIP -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One Way Audio
Hi Ahmed, do you use any media relay? if not, the audio problem is strictly related to your devices. Regards, Bogdan Ahmed Munir wrote: But now I'm facing weird problem, while using non-svn version 1.6 I was able to call to my asterisk boxes and media was passing on both ways. But when I recompile svn version 1.6 and make a call there is only one way voice from eyebeam to twinkle i.e. eyebeam - opensips -- asterisk -- twinkle twinkle can hear from eyebeam side --- eyebeam can't hear from twinkle side Opensips and Asterisk both hosted on Public IPs and UAC are located at private network. Firewall is permitted on both servers and I'm using stun for my UAC. Kindly advise to sort this problem? But I don't understand why was media is passing both ways when using non-svn version? Further added, I am also using module dispatcher. -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] One Way Audio
Hi Irina,
Thanks for reply. After looking in forums I observed that on opensips
version 1.6 has a bug and its bug fix is uploaded on svn. I recompile svn
version 1.6 and test it and working ok.
But now I'm facing weird problem, while using non-svn version 1.6 I was able
to call to my asterisk boxes and media was passing on both ways. But when I
recompile svn version 1.6 and make a call there is only one way voice from
eyebeam to twinkle i.e.
eyebeam - opensips -- asterisk -- twinkle
twinkle can hear from eyebeam side
---
eyebeam can't hear from twinkle side
Opensips and Asterisk both hosted on Public IPs and UAC are located at
private network. Firewall is permitted on both servers and I'm using stun
for my UAC.
Kindly advise to sort this problem? But I don't understand why was media is
passing both ways when using non-svn version?
Further added, I am also using module dispatcher.
Date: Wed, 06 Jan 2010 16:36:44 +0200
From: Irina Stanescu istane...@opensips.org
Subject: Re: [OpenSIPS-Users] How to increase cache in opensips tables
To: OpenSIPS users mailling list users@lists.opensips.org
Message-ID: 4b449ffc.5050...@opensips.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello Ahmed,
Firstly, I need to see the log so I could understand better the error
you get. I don't think the problem is that the cache is too small.
Also, you cannot use 0 for the group id, the documentation says:
group_id
This argument represents the group id to be matched. It can be an
integer string or a string pvar. If the group_id argument is 0, the
query can match any group in the cached address table
Secondly, as the name suggests, the ip column is reserved for IPs only.
You cannot add domain name addresses to this column.
Regards,
Irina Stanescu
Ahmed Munir wrote:
Hi,
I'm using permission module's function check_source_address(), the
problem I'm facing is that I can not add not than more 8 IPs in
address table, but I want to permit more than 100 IPs. I only want to
use these IPs on group 0 what I am using. When I enter more than 8 IPs
in address table and make a call, I observe a message i.e. not found
in hash table.My opensips.cfg configuration for check_source_address()
is listed below;
if (is_method(INVITE) check_source_address(0)) {
log(INVITE###);
ds_select_domain(1,4);
forward();
route(1);
log(#END);
setflag(1);
}
Kindly advise me how to increase cache of OpenSIPs database tables so
I can reslove my case. Further added, how can I enter domain name in
'ip' column section of address table i.e. abc.com http://abc.com
can't be used and gives me an error, kindly advise this well.
--
Regards,
Ahmed Munir
--
Regards,
Ahmed Munir
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] One Way Audio Using X-Lite, OpenSIPS Asterisk
Hi,
I am using the following config with Opensips and having a problem with one way
audio. When connecting the softphone directly to asterisk that runs on the same
machine audio passes without any problems. Firewalls are all open and
Zoiper/Snom phones connect without issue.
If anyone could offer some advice it would be much appreciated as I'm tearing
my hear out :-)
# --- global configuration parameters
debug=3 # debug level (cmd line: -dd)
fork=yes
log_stderror=yes # (cmd line: -E)
/* Uncomment these lines to enter debugging mode
fork=no
log_stderror=yes
*/
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
listen=udp:IP ADDRESS:5060
children=4
# -- module loading --
#set module path
mpath=/usr/local/lib64/opensips/modules/
# Uncomment this if you want to use SQL database
loadmodule db_mysql.so
loadmodule sl.so
loadmodule tm.so
loadmodule signaling.so
loadmodule rr.so
loadmodule maxfwd.so
loadmodule usrloc.so
loadmodule registrar.so
loadmodule textops.so
loadmodule mi_fifo.so
loadmodule mediaproxy.so
loadmodule xlog.so
loadmodule dialog.so
loadmodule load_balancer.so
loadmodule mi_datagram.so
# Uncomment this if you want digest authentication
# db_mysql.so must be loaded !
#loadmodule auth.so
#loadmodule auth_db.so
# !! Nathelper
loadmodule nathelper.so
# - setting module-specific parameters ---
# -- mi_fifo params --
modparam(mi_fifo, fifo_name, /tmp/opensips_fifo)
modparam(mi_datagram, socket_name, /tmp/opensips.sock)
modparam(mi_datagram, unix_socket_mode, 0600)
modparam(mi_datagram, socket_timeout, 2000)
# -- usrloc params --
modparam(usrloc, db_mode, 0)
# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line
#modparam(usrloc, db_mode, 2)
# -- auth params --
# Uncomment if you are using auth module
#modparam(auth_db, calculate_ha1, yes)
#
# If you set calculate_ha1 parameter to yes (which true in this config),
# uncomment also the following parameter)
#modparam(auth_db, password_column, password)
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam(rr, enable_full_lr, 1)
# !! Nathelper
modparam(usrloc,nat_bflag,6)
modparam(nathelper,sipping_bflag,8)
modparam(nathelper, ping_nated_only, 1) # Ping only clients behind NAT
# -- MediaProxy --
modparam(mediaproxy, mediaproxy_socket,
/var/run/mediaproxy/dispatcher.sock)
modparam(mediaproxy, mediaproxy_timeout, 500)
modparam(dialog, dlg_flag, 13)
modparam(dialog, db_mode, 1)
modparam(dialog, db_url, DB URL)
modparam(load_balancer, db_url,DB URL)
# - request routing logic ---
# main routing logic
route{
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header(10)) {
sl_send_reply(483,Too Many Hops);
exit;
};
if (msg:len= 2048 ) {
sl_send_reply(513, Message too big);
exit;
};
# !! Nathelper
# Special handling for NATed clients; first, NAT test is
# executed: it looks for via!=received and RFC1918 addresses
# in Contact (may fail if line-folding is used); also,
# the received test should, if completed, should check all
# vias for rpesence of received
if (nat_uac_test(3))
{
# Allow RR-ed requests, as these may indicate that
# a NAT-enabled proxy takes care of it; unless it is
# a REGISTER
if (is_method(REGISTER) || !is_present_hf(Record-Route)) {
log(LOG:Someone trying to register from private IP, rewriting\n);
# This will work only for user agents that support symmetric
# communication. We tested quite many of them and majority is
# smart enough to be symmetric. In some phones it takes a
# configuration option. With Cisco 7960, it is called
# NAT_Enable=Yes, with kphone it is called symmetric media and
# symmetric signalling.
# Rewrite contact with source IP of signalling
fix_nated_contact();
if ( is_method(INVITE) ) {
fix_nated_sdp(1); # Add direction=active to SDP
};
force_rport(); # Add rport parameter to topmost Via
setbflag(6);# Mark as NATed
# if you want sip nat pinging
# setbflag(8);
};
};
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf(P-hint: rr-enforced\r\n);
route(1);
exit;
};
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
if (!is_method(REGISTER))
record_route();
if (!uri==myself) {
# mark routing logic in request
append_hf(P-hint: outbound\r\n);
route(1);
exit;
};
# if the request is for other domain use UsrLoc
Re: [OpenSIPS-Users] One Way Audio Using X-Lite, OpenSIPS Asterisk
On Friday 23 October 2009 11:01:11 Ross Beer wrote: Hi, I am using the following config with Opensips and having a problem with one way audio. When connecting the softphone directly to asterisk that runs on the same machine audio passes without any problems. Firewalls are all open and Zoiper/Snom phones connect without issue. If anyone could offer some advice it would be much appreciated as I'm tearing my hear out :-) Better if you attach some SIP trace of a working an a non working call -- Raúl Alexis Betancor Santana Dimensión Virtual ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One Way Audio Using X-Lite, OpenSIPS Asterisk (Ross Beer)
On Friday 23 October 2009 14:19:45 Ross Beer wrote: Hi, Here is the sip trace for the calls, it strange as all other phone work except X-Lite, it appears that sound is not getting from the softphone to the server. Though if the softphone talks directly to asterisk it works ok. This is the case if MediaProxy is used or not. There is a lack of codecs in the invite which is strange as I have 4 enabled on the server and the softphone. Seems you don't look on the wright place .. because your X-Lite is offering PCMU ... just look at the m= line on the first invite. INVITE sip:160@SERVER IP ADDRESS SIP/2.0 Via: SIP/2.0/UDP ROUTER IP ADDRESS:9302;branch=z9hG4bK-d8754z-4e352701ef65e42a-1---d8754z-;rport Max-Forwards: 69 Contact: sip:10002*200@ROUTER IP ADDRESS:9302 To: 160sip:160@SERVER IP ADDRESS From: Rosssip:10002*200@SERVER IP ADDRESS;tag=ad038800 Call-ID: ZjQ0MTE2MzI1OTE0NjA5MDEzYWExYTljNDM5ODFmNjM. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: X-Lite release 1103k stamp 53621 Content-Length: 236 v=0 o=- 0 2 IN IP4 192.168.1.222 s=CounterPath X-Lite 3.0 c=IN IP4 ROUTER IP ADDRESS t=0 0 m=audio 10006 RTP/AVP 0 101 a=alt:1 1 : 9ImKPFaa h9RvD+sl 192.168.1.222 10006 a=fmtp:101 0-15 a=rtpmap:101 telephone-event/8000 a=sendrecv Umm ... umm ... by ROUTER IP ADDRESS do you mean your public IP on your NAT router ? ... does your router have SIP-ALG activated ?, that could explain the problem. This INVITE is the one that just arrive at your proxy? ... if so .. your NAT router is doing sip-alg .. so mangling all the SIP dialog, and they usually does a very bad job with that. -- Raúl Alexis Betancor Santana Dimensión Virtual ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One Way Audio Using X-Lite, OpenSIPS Asterisk (Ross Beer)
Do you have 'discover global IP' and 'use ICE' setting enabled in X-lite? I remember I had some issues in the past with that... let your proxy handle everything for you. -- /Saúl http://www.saghul.net | http://www.sipdoc.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One Way Audio
0016e640d47e2c8bcd047677c...@google.com
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Hi Duane=2C
=20
Here is my config and SIP trace.
=20
There is one interesting thing in the SIP trace=2C that is the SDP codecs. =
I have G711u=2C G711a enabled on both asterisk and the softphone however X-=
Lite does not show G711u or G711a.
=20
Is there something in the config that would remove these?
=20
Thanks=2C
=20
Ross
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
# NOTE !! This config is EXPERIMENTAL !
#
# --- global configuration parameters
debug=3D3 # debug level (cmd line: -dd)
fork=3Dyes
log_stderror=3Dyes # (cmd line: -E)
/* Uncomment these lines to enter debugging mode=20
fork=3Dno
log_stderror=3Dyes
*/
check_via=3Dno # (cmd. line: -v)
dns=3Dno # (cmd. line: -r)
rev_dns=3Dno # (cmd. line: -R)
listen=3Dudp:IP ADDRESS:5060
children=3D4
# -- module loading --
#set module path
mpath=3D/usr/local/lib64/opensips/modules/
# Uncomment this if you want to use SQL database
loadmodule db_mysql.so
loadmodule sl.so
loadmodule tm.so
loadmodule signaling.so
loadmodule rr.so
loadmodule maxfwd.so
loadmodule usrloc.so
loadmodule registrar.so
loadmodule textops.so
loadmodule mi_fifo.so
loadmodule mediaproxy.so
loadmodule xlog.so
loadmodule dialog.so
loadmodule load_balancer.so
loadmodule mi_datagram.so
# Uncomment this if you want digest authentication
# db_mysql.so must be loaded !
#loadmodule auth.so
#loadmodule auth_db.so
# !! Nathelper
loadmodule nathelper.so
# - setting module-specific parameters ---
# -- mi_fifo params --
modparam(mi_fifo=2C fifo_name=2C /tmp/opensips_fifo)
modparam(mi_datagram=2C socket_name=2C /tmp/opensips.sock)
modparam(mi_datagram=2C unix_socket_mode=2C 0600)
modparam(mi_datagram=2C socket_timeout=2C 2000)
# -- usrloc params --
modparam(usrloc=2C db_mode=2C 0)
# Uncomment this if you want to use SQL database=20
# for persistent storage and comment the previous line
#modparam(usrloc=2C db_mode=2C 2)
# -- auth params --
# Uncomment if you are using auth module
#modparam(auth_db=2C calculate_ha1=2C yes)
#
# If you set calculate_ha1 parameter to yes (which true in this config)=
=2C=20
# uncomment also the following parameter)
#modparam(auth_db=2C password_column=2C password)
# -- rr params --
# add value to =3Blr param to make some broken UAs happy
modparam(rr=2C enable_full_lr=2C 1)
# !! Nathelper
modparam(usrloc=2Cnat_bflag=2C6)
modparam(nathelper=2Csipping_bflag=2C8)
modparam(nathelper=2C ping_nated_only=2C 1) # Ping only clients behin=
d NAT
# -- MediaProxy --
modparam(mediaproxy=2C mediaproxy_socket=2C /var/run/mediaproxy/dispat=
cher.sock)
modparam(mediaproxy=2C mediaproxy_timeout=2C 500)
modparam(dialog=2C dlg_flag=2C 13)
modparam(dialog=2C db_mode=2C 1)
modparam(dialog=2C db_url=2C DB URL)
modparam(load_balancer=2C db_url=2CDB URL)
# - request routing logic ---
# main routing logic
route{
# initial sanity checks -- messages with
# max_forwards=3D=3D0=2C or excessively long requests
if (!mf_process_maxfwd_header(10)) {
sl_send_reply(483=2CToo Many Hops)=3B
exit=3B
}=3B
if (msg:len=3D 2048 ) {
sl_send_reply(513=2C Message too big)=3B
exit=3B
}=3B
# !! Nathelper
# Special handling for NATed clients=3B first=2C NAT test is
# executed: it looks for via!=3Dreceived and RFC1918 addresses
# in Contact (may fail if line-folding is used)=3B also=2C
# the received test should=2C if completed=2C should check all
# vias for rpesence of received
if (nat_uac_test(3))=20
{
# Allow RR-ed requests=2C as these may indicate that
# a NAT-enabled proxy takes care of it=3B unless it is
# a REGISTER
if (is_method(REGISTER) || !is_present_hf(Record-Route)) {
log(LOG:Someone trying to register from private IP=2C rewriting\n)=3B
# This will work only for user agents that support symmetric
# communication. We tested quite many of them and majority is
# smart enough to be symmetric. In some phones it takes a=20
# configuration option. With Cisco 7960=2C it is called=20
# NAT_Enable=3DYes=2C with kphone it is called symmetric media and=20
# symmetric signalling.
# Rewrite contact with source IP of signalling
fix_nated_contact()=3B
if ( is_method(INVITE) ) {
fix_nated_sdp(1)=3B # Add direction=3Dactive to SDP
}=3B
force_rport()=3B # Add rport parameter to topmost Via
setbflag(6)=3B# Mark as NATed
# if you want sip nat pinging
# setbflag(8)=3B
}=3B
}=3B
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark
[OpenSIPS-Users] One Way Audio
I have a server located on the internet running opensips and asterisk. When registering directly to asterisk I can perform echo tests and make calls. If I register to Opensips and use the load_balance there is one way audio. I can hear sounds coming from the asterisk server but sound from the soft phone does not reach asterisk. I can confirm this when looking at a rtp debug on asterisk. I can see that traffic is passing from the soft phone when performing a wire shark trace to the server and it also shows that some RTP packet are being passed out and back into my local address. This does not happen if I register directly to asterisk. Any advice you can offer would be appreciated. Opensips shouldn't effect the RTP if it only load balances? Thanks, Ross _ Did you know you can get Messenger on your mobile? http://clk.atdmt.com/UKM/go/174426567/direct/01/___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One Way Audio
NHi Duane, There are is a firewall on the server end however all ports are open, no NAT at the server end however there is NATing on the end of the soft phone. Though when registering with asterisk directly there is no issue. Regards, Ross Date: Wed, 21 Oct 2009 15:23:04 + Subject: Re: [OpenSIPS-Users] One Way Audio From: duane.lar...@gmail.com To: ross_b...@hotmail.com Are there any firewalls or NATing involved? On Oct 21, 2009 10:13am, Ross Beer ross_b...@hotmail.com wrote: I have a server located on the internet running opensips and asterisk. When registering directly to asterisk I can perform echo tests and make calls. If I register to Opensips and use the load_balance there is one way audio. I can hear sounds coming from the asterisk server but sound from the soft phone does not reach asterisk. I can confirm this when looking at a rtp debug on asterisk. I can see that traffic is passing from the soft phone when performing a wire shark trace to the server and it also shows that some RTP packet are being passed out and back into my local address. This does not happen if I register directly to asterisk. Any advice you can offer would be appreciated. Opensips shouldn't effect the RTP if it only load balances? Thanks, Ross Did you know you can get Messenger on your mobile? Learn more. _ Use Windows Live Messenger for free on selected mobiles http://clk.atdmt.com/UKM/go/174426567/direct/01/___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One Way Audio
So in the wireshark trace you see RTP traffic coming from the Asterisk servers IP address, but what about the traffic coming from the softphone? What IP address is that going towards? On Oct 21, 2009 10:35am, Ross Beer ross_b...@hotmail.com wrote: NHi Duane, There are is a firewall on the server end however all ports are open, no NAT at the server end however there is NATing on the end of the soft phone. Though when registering with asterisk directly there is no issue. Regards, Ross Date: Wed, 21 Oct 2009 15:23:04 + Subject: Re: [OpenSIPS-Users] One Way Audio From: duane.lar...@gmail.com To: ross_b...@hotmail.com Are there any firewalls or NATing involved? On Oct 21, 2009 10:13am, Ross Beer ross_b...@hotmail.com wrote: I have a server located on the internet running opensips and asterisk. When registering directly to asterisk I can perform echo tests and make calls. If I register to Opensips and use the load_balance there is one way audio. I can hear sounds coming from the asterisk server but sound from the soft phone does not reach asterisk. I can confirm this when looking at a rtp debug on asterisk. I can see that traffic is passing from the soft phone when performing a wire shark trace to the server and it also shows that some RTP packet are being passed out and back into my local address. This does not happen if I register directly to asterisk. Any advice you can offer would be appreciated. Opensips shouldn't effect the RTP if it only load balances? Thanks, Ross Did you know you can get Messenger on your mobile? Learn more. Use Windows Live Messenger for free on selected mobiles. Learn more. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One Way Audio
Yep, traffic comes from the asterisk server and can be heard on the softphone, but when the echo test starts no audo can be heard. Therfore the flow goes like this: Asterisk --- Opensips Softphone But NOT: Softphone --- Opensips Asterisk Which is strange, if opensips is not in the path all works correctly. Also if I call out using a SIP provider I also get two way audio, but not when talking directly to asterisk. Regards, Ross From: ross_b...@hotmail.com To: duane.lar...@gmail.com; users@lists.opensips.org Subject: RE: [OpenSIPS-Users] One Way Audio Date: Wed, 21 Oct 2009 16:35:28 +0100 NHi Duane, There are is a firewall on the server end however all ports are open, no NAT at the server end however there is NATing on the end of the soft phone. Though when registering with asterisk directly there is no issue. Regards, Ross Date: Wed, 21 Oct 2009 15:23:04 + Subject: Re: [OpenSIPS-Users] One Way Audio From: duane.lar...@gmail.com To: ross_b...@hotmail.com Are there any firewalls or NATing involved? On Oct 21, 2009 10:13am, Ross Beer ross_b...@hotmail.com wrote: I have a server located on the internet running opensips and asterisk. When registering directly to asterisk I can perform echo tests and make calls. If I register to Opensips and use the load_balance there is one way audio. I can hear sounds coming from the asterisk server but sound from the soft phone does not reach asterisk. I can confirm this when looking at a rtp debug on asterisk. I can see that traffic is passing from the soft phone when performing a wire shark trace to the server and it also shows that some RTP packet are being passed out and back into my local address. This does not happen if I register directly to asterisk. Any advice you can offer would be appreciated. Opensips shouldn't effect the RTP if it only load balances? Thanks, Ross Did you know you can get Messenger on your mobile? Learn more. Use Windows Live Messenger for free on selected mobiles. Learn more. _ Did you know you can get Messenger on your mobile? http://clk.atdmt.com/UKM/go/174426567/direct/01/___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One Way Audio
It looks like it is sending in to the server's IP address and back to it's self which is strange. I think this has something to do with the SDP and possibly my router. I am doing an echo test so audio should come back, however Asterisk should stay in the media path as it does when directly using asterisk. If I use a different network there isn't a problem however directly using asterisk on the problem network has no issues. Ideally I would like to resolve this issue so all networks can use OpenSips. I am currently testing MediaProxy however it does not appear to receive the RTP stream from the soft phone either. Thank you for you help, Ross Date: Wed, 21 Oct 2009 17:55:10 + Subject: Re: RE: [OpenSIPS-Users] One Way Audio From: duane.lar...@gmail.com To: ross_b...@hotmail.com In the wireshark trace what IP is the softphone sending the RTP packets to? Whats the destination? Is it actually sending the RTP to the Asterisk box? On Oct 21, 2009 11:15am, Ross Beer ross_b...@hotmail.com wrote: Yep, traffic comes from the asterisk server and can be heard on the softphone, but when the echo test starts no audo can be heard. Therfore the flow goes like this: Asterisk --- Opensips Softphone But NOT: Softphone --- Opensips Asterisk Which is strange, if opensips is not in the path all works correctly. Also if I call out using a SIP provider I also get two way audio, but not when talking directly to asterisk. Regards, Ross Date: Wed, 21 Oct 2009 15:40:38 + Subject: Re: RE: [OpenSIPS-Users] One Way Audio From: duane.lar...@gmail.com To: ross_b...@hotmail.com; duane.lar...@gmail.com CC: users@lists.opensips.org So in the wireshark trace you see RTP traffic coming from the Asterisk servers IP address, but what about the traffic coming from the softphone? What IP address is that going towards? On Oct 21, 2009 10:35am, Ross Beer ross_b...@hotmail.com wrote: NHi Duane, There are is a firewall on the server end however all ports are open, no NAT at the server end however there is NATing on the end of the soft phone. Though when registering with asterisk directly there is no issue. Regards, Ross Date: Wed, 21 Oct 2009 15:23:04 + Subject: Re: [OpenSIPS-Users] One Way Audio From: duane.lar...@gmail.com To: ross_b...@hotmail.com Are there any firewalls or NATing involved? On Oct 21, 2009 10:13am, Ross Beer ross_b...@hotmail.com wrote: I have a server located on the internet running opensips and asterisk. When registering directly to asterisk I can perform echo tests and make calls. If I register to Opensips and use the load_balance there is one way audio. I can hear sounds coming from the asterisk server but sound from the soft phone does not reach asterisk. I can confirm this when looking at a rtp debug on asterisk. I can see that traffic is passing from the soft phone when performing a wire shark trace to the server and it also shows that some RTP packet are being passed out and back into my local address. This does not happen if I register directly to asterisk. Any advice you can offer would be appreciated. Opensips shouldn't effect the RTP if it only load balances? Thanks, Ross Did you know you can get Messenger on your mobile? Learn more. Use Windows Live Messenger for free on selected mobiles. Learn more. Stay in touch with your friends through Messenger on your mobile. Learn more. _ Stay in touch with your friends through Messenger on your mobile http://clk.atdmt.com/UKM/go/174426567/direct/01/___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One Way Audio
Hi Ross, Actually you do not need any media relay (mediaproxy or rtpproxy) here. As time as Asterisk is on the public side, it should directly work even with a natted client. What you have to check is the SDP received by the nated client in the 200 OK - check what IP it is instructed to send traffic to. Normally it should be the IP of Asterisk. Regards, Bogdan Ross Beer wrote: It looks like it is sending in to the server's IP address and back to it's self which is strange. I think this has something to do with the SDP and possibly my router. I am doing an echo test so audio should come back, however Asterisk should stay in the media path as it does when directly using asterisk. If I use a different network there isn't a problem however directly using asterisk on the problem network has no issues. Ideally I would like to resolve this issue so all networks can use OpenSips. I am currently testing MediaProxy however it does not appear to receive the RTP stream from the soft phone either. Thank you for you help, Ross Date: Wed, 21 Oct 2009 17:55:10 + Subject: Re: RE: [OpenSIPS-Users] One Way Audio From: duane.lar...@gmail.com To: ross_b...@hotmail.com In the wireshark trace what IP is the softphone sending the RTP packets to? Whats the destination? Is it actually sending the RTP to the Asterisk box? On Oct 21, 2009 11:15am, Ross Beer ross_b...@hotmail.com wrote: Yep, traffic comes from the asterisk server and can be heard on the softphone, but when the echo test starts no audo can be heard. Therfore the flow goes like this: Asterisk --- Opensips Softphone But NOT: Softphone --- Opensips Asterisk Which is strange, if opensips is not in the path all works correctly. Also if I call out using a SIP provider I also get two way audio, but not when talking directly to asterisk. Regards, Ross Date: Wed, 21 Oct 2009 15:40:38 + Subject: Re: RE: [OpenSIPS-Users] One Way Audio From: duane.lar...@gmail.com To: ross_b...@hotmail.com; duane.lar...@gmail.com CC: users@lists.opensips.org So in the wireshark trace you see RTP traffic coming from the Asterisk servers IP address, but what about the traffic coming from the softphone? What IP address is that going towards? On Oct 21, 2009 10:35am, Ross Beer ross_b...@hotmail.com wrote: NHi Duane, There are is a firewall on the server end however all ports are open, no NAT at the server end however there is NATing on the end of the soft phone. Though when registering with asterisk directly there is no issue. Regards, Ross Date: Wed, 21 Oct 2009 15:23:04 + Subject: Re: [OpenSIPS-Users] One Way Audio From: duane.lar...@gmail.com To: ross_b...@hotmail.com Are there any firewalls or NATing involved? On Oct 21, 2009 10:13am, Ross Beer ross_b...@hotmail.com wrote: I have a server located on the internet running opensips and asterisk. When registering directly to asterisk I can perform echo tests and make calls. If I register to Opensips and use the load_balance there is one way audio. I can hear sounds coming from the asterisk server but sound from the soft phone does not reach asterisk. I can confirm this when looking at a rtp debug on asterisk. I can see that traffic is passing from the soft phone when performing a wire shark trace to the server and it also shows that some RTP packet are being passed out and back into my local address. This does not happen if I register directly to asterisk. Any advice you can offer would be appreciated. Opensips shouldn't effect the RTP if it only load balances? Thanks, Ross Did you know you can get Messenger on your mobile? Learn more. Use Windows Live Messenger for free on selected mobiles. Learn more. Stay in touch with your friends through Messenger on your mobile. Learn more. Stay in touch with your friends through Messenger on your mobile. Learn more. http://clk.atdmt.com/UKM/go/174426567/direct/01/ ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
Hi Julian, You can still handle the NAT wih COMEDIA even for T.38, but you have to handle the re-INVITE also . In your scenario, who is generating the re-INVITE? Regards, Bogdan Julian Yap wrote: The full story is that I was looking to get T.38 working behind NAT. Unfortunately, no matter what I tried, it wouldn't work behind NAT. I had the initial INVITE (G.711) working fine but when there was the T.38 re-INVITE, the RTP media would connect up fine but just wouldn't negotiate properly with T.38. Very strange as it worked fine with the UA behind a public IP. In the end, I implemented RTPProxy and T.38 works fine behind NAT. - Julian On Sun, Feb 15, 2009 at 1:25 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Julian, That is cool - in this way you save a lot of bandwidth and processing power with media relaying. Regards, Bogdan Julian Yap wrote: Hi all, I eventually played around with the Audiocodes box and enabled some settings so it worked with Comedia support. Thanks, Julian On 2/10/09, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: HI Julian, If it has, you can actually force it by adding direction=active into SDP as indication. See fix_nated_sdp(1) : http://www.opensips.org/html/docs/modules/1.4.x/nathelper.html#id270439 Regards, Bogdan Julian Yap wrote: Thanks all. I'll check to see if the AudioCodes gateway does have comedia support. That clarifies some half baked NAT/RTP knowledge in my head. - Julian On 2/10/09, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Olle, Johansson Olle E wrote: 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo: 2009/2/10 julianok...@gmail.com: You don't know if RtpProxy should be running, does it mean you are trying to use it or not? I don't want to spend time inspecting what you want to do by reading your config, sorry. Yeah, I'm trying not to run RTPProxy. After more testing, I'm thinking I may need to. You cannot decide if you need RtpProxy or not based on testing, it's pure theory: A RTP proxy is NOT needed when (assuming the proxy has in the public internet): - Both caller and callee have public IP or use STUN. - Both caller and callee are in the *SAME* private LAN. - The caller is in a private LAN and the callee has public IP and supports Comedia mode (typical in some media servers and gateways). - The callee is in a private LAN and the caller has public IP and supports Comedia mode. A RTP proxy is needed when: - Caller is in private LAN (with no STUN) and callee in public internet (and not supporting Comedia). - Caller and callee are in different private LAN's with no STUN. I would like to add that it's the device that can't receive audio that needs the RTP proxy to get incoming audio. If both devices are on private IP's, there's going to be two RTP proxys involved if they're on different SIP networks. Each SIP service needs an RTP proxy for supporting their local users. To simplify: - If my user is on a private IP and sends an INVITE, add RTP proxy handling to the INVITE - If my user receives a call and sends a 200 OK, add RTP proxy handling to the 200 OK This logic is simple but not efficientTheoretically, if a call has already a leg in public net, there is not need for a media relay for traversing the nat. The only requirement is that all the devices to support symmetric media (comedia support). So, after the caller proxy forced RTPproxy, the callee should not do the same because the SDP already have a public IP, the nat traversal works even if the callee is behind a nat. Regards, Bogdan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
In an example scenario, the re-INVITE is handled by the end device. So: PSTN Fax -- GW -- OpenSIPS -- UA (ATA attached to Fax machine) UA answers the call and then sends the re-INVITE which is correct as that is the terminating side. I read this RFC http://tools.ietf.org/html/draft-mule-sip-t38callflows-02 which was quite handy. :P The re-INVITE get accepted and RTP communication starts... However, for some reason, the T.38 part fails. In theory it should work but doesn't for me. Perhaps it's something wrong with my config at the time and the handling of the re-INVITE and NAT. Or perhaps it was some obscure issue with the GW and T.38 communications and timing, etc... Eventually I re-implemented it all with RTPProxy and that worked for me first time, inbound and outbound. Perhaps if someone has a clean working config with re-INVITE without using RTPProxy or MediaProxy, I can try that. Seems like all the example configs out there are used with a RTP proxy. - Julian On Mon, Feb 16, 2009 at 1:04 PM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Julian, You can still handle the NAT wih COMEDIA even for T.38, but you have to handle the re-INVITE also . In your scenario, who is generating the re-INVITE? Regards, Bogdan Julian Yap wrote: The full story is that I was looking to get T.38 working behind NAT. Unfortunately, no matter what I tried, it wouldn't work behind NAT. I had the initial INVITE (G.711) working fine but when there was the T.38 re-INVITE, the RTP media would connect up fine but just wouldn't negotiate properly with T.38. Very strange as it worked fine with the UA behind a public IP. In the end, I implemented RTPProxy and T.38 works fine behind NAT. - Julian On Sun, Feb 15, 2009 at 1:25 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Julian, That is cool - in this way you save a lot of bandwidth and processing power with media relaying. Regards, Bogdan Julian Yap wrote: Hi all, I eventually played around with the Audiocodes box and enabled some settings so it worked with Comedia support. Thanks, Julian On 2/10/09, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: HI Julian, If it has, you can actually force it by adding direction=active into SDP as indication. See fix_nated_sdp(1) : http://www.opensips.org/html/docs/modules/1.4.x/nathelper.html#id270439 Regards, Bogdan Julian Yap wrote: Thanks all. I'll check to see if the AudioCodes gateway does have comedia support. That clarifies some half baked NAT/RTP knowledge in my head. - Julian On 2/10/09, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Olle, Johansson Olle E wrote: 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo: 2009/2/10 julianok...@gmail.com: You don't know if RtpProxy should be running, does it mean you are trying to use it or not? I don't want to spend time inspecting what you want to do by reading your config, sorry. Yeah, I'm trying not to run RTPProxy. After more testing, I'm thinking I may need to. You cannot decide if you need RtpProxy or not based on testing, it's pure theory: A RTP proxy is NOT needed when (assuming the proxy has in the public internet): - Both caller and callee have public IP or use STUN. - Both caller and callee are in the *SAME* private LAN. - The caller is in a private LAN and the callee has public IP and supports Comedia mode (typical in some media servers and gateways). - The callee is in a private LAN and the caller has public IP and supports Comedia mode. A RTP proxy is needed when: - Caller is in private LAN (with no STUN) and callee in public internet (and not supporting Comedia). - Caller and callee are in different private LAN's with no STUN. I would like to add that it's the device that can't receive audio that needs the RTP proxy to get incoming audio. If both devices are on private IP's, there's going to be two RTP proxys involved if they're on different SIP networks. Each SIP service needs an RTP proxy for supporting their local users. To simplify: - If my user is on a private IP and sends an INVITE, add RTP proxy handling to the INVITE - If my user receives a call and sends a 200 OK, add RTP proxy handling to the 200 OK This logic is simple but not efficientTheoretically, if a call has already a leg in public net, there is not need for a media relay for traversing the nat. The only requirement is that all the devices to support symmetric media (comedia support). So, after the caller proxy forced RTPproxy, the callee should not do the same because the SDP already have a public IP, the nat traversal works even if the callee is behind a nat. Regards, Bogdan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
Hi Julian, That is cool - in this way you save a lot of bandwidth and processing power with media relaying. Regards, Bogdan Julian Yap wrote: Hi all, I eventually played around with the Audiocodes box and enabled some settings so it worked with Comedia support. Thanks, Julian On 2/10/09, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: HI Julian, If it has, you can actually force it by adding direction=active into SDP as indication. See fix_nated_sdp(1) : http://www.opensips.org/html/docs/modules/1.4.x/nathelper.html#id270439 Regards, Bogdan Julian Yap wrote: Thanks all. I'll check to see if the AudioCodes gateway does have comedia support. That clarifies some half baked NAT/RTP knowledge in my head. - Julian On 2/10/09, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Olle, Johansson Olle E wrote: 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo: 2009/2/10 julianok...@gmail.com: You don't know if RtpProxy should be running, does it mean you are trying to use it or not? I don't want to spend time inspecting what you want to do by reading your config, sorry. Yeah, I'm trying not to run RTPProxy. After more testing, I'm thinking I may need to. You cannot decide if you need RtpProxy or not based on testing, it's pure theory: A RTP proxy is NOT needed when (assuming the proxy has in the public internet): - Both caller and callee have public IP or use STUN. - Both caller and callee are in the *SAME* private LAN. - The caller is in a private LAN and the callee has public IP and supports Comedia mode (typical in some media servers and gateways). - The callee is in a private LAN and the caller has public IP and supports Comedia mode. A RTP proxy is needed when: - Caller is in private LAN (with no STUN) and callee in public internet (and not supporting Comedia). - Caller and callee are in different private LAN's with no STUN. I would like to add that it's the device that can't receive audio that needs the RTP proxy to get incoming audio. If both devices are on private IP's, there's going to be two RTP proxys involved if they're on different SIP networks. Each SIP service needs an RTP proxy for supporting their local users. To simplify: - If my user is on a private IP and sends an INVITE, add RTP proxy handling to the INVITE - If my user receives a call and sends a 200 OK, add RTP proxy handling to the 200 OK This logic is simple but not efficientTheoretically, if a call has already a leg in public net, there is not need for a media relay for traversing the nat. The only requirement is that all the devices to support symmetric media (comedia support). So, after the caller proxy forced RTPproxy, the callee should not do the same because the SDP already have a public IP, the nat traversal works even if the callee is behind a nat. Regards, Bogdan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
The full story is that I was looking to get T.38 working behind NAT. Unfortunately, no matter what I tried, it wouldn't work behind NAT. I had the initial INVITE (G.711) working fine but when there was the T.38 re-INVITE, the RTP media would connect up fine but just wouldn't negotiate properly with T.38. Very strange as it worked fine with the UA behind a public IP. In the end, I implemented RTPProxy and T.38 works fine behind NAT. - Julian On Sun, Feb 15, 2009 at 1:25 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Julian, That is cool - in this way you save a lot of bandwidth and processing power with media relaying. Regards, Bogdan Julian Yap wrote: Hi all, I eventually played around with the Audiocodes box and enabled some settings so it worked with Comedia support. Thanks, Julian On 2/10/09, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: HI Julian, If it has, you can actually force it by adding direction=active into SDP as indication. See fix_nated_sdp(1) : http://www.opensips.org/html/docs/modules/1.4.x/nathelper.html#id270439 Regards, Bogdan Julian Yap wrote: Thanks all. I'll check to see if the AudioCodes gateway does have comedia support. That clarifies some half baked NAT/RTP knowledge in my head. - Julian On 2/10/09, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Olle, Johansson Olle E wrote: 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo: 2009/2/10 julianok...@gmail.com: You don't know if RtpProxy should be running, does it mean you are trying to use it or not? I don't want to spend time inspecting what you want to do by reading your config, sorry. Yeah, I'm trying not to run RTPProxy. After more testing, I'm thinking I may need to. You cannot decide if you need RtpProxy or not based on testing, it's pure theory: A RTP proxy is NOT needed when (assuming the proxy has in the public internet): - Both caller and callee have public IP or use STUN. - Both caller and callee are in the *SAME* private LAN. - The caller is in a private LAN and the callee has public IP and supports Comedia mode (typical in some media servers and gateways). - The callee is in a private LAN and the caller has public IP and supports Comedia mode. A RTP proxy is needed when: - Caller is in private LAN (with no STUN) and callee in public internet (and not supporting Comedia). - Caller and callee are in different private LAN's with no STUN. I would like to add that it's the device that can't receive audio that needs the RTP proxy to get incoming audio. If both devices are on private IP's, there's going to be two RTP proxys involved if they're on different SIP networks. Each SIP service needs an RTP proxy for supporting their local users. To simplify: - If my user is on a private IP and sends an INVITE, add RTP proxy handling to the INVITE - If my user receives a call and sends a 200 OK, add RTP proxy handling to the 200 OK This logic is simple but not efficientTheoretically, if a call has already a leg in public net, there is not need for a media relay for traversing the nat. The only requirement is that all the devices to support symmetric media (comedia support). So, after the caller proxy forced RTPproxy, the callee should not do the same because the SDP already have a public IP, the nat traversal works even if the callee is behind a nat. Regards, Bogdan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
2009/2/10 Johansson Olle E o...@edvina.net: If both devices are on private IP's, there's going to be two RTP proxys involved if they're on different SIP networks. Each SIP service needs an RTP proxy for supporting their local users. Hi, I don't fully agree on it: alice --- (NAT A) --- ProxyA RtpProxyA --- ProxyB RtpProxyB --- (NAT B) --- bob In this case, when alice calls bob, ProxyA will apply RtpProxyA so the SDP will contain a public IP. Since ProxyB knows that bob is registered behind NAT, it will try to apply RtpProxyB but this will fail because the incoming SDP contains a line: a=nortpproxy:yes This line was added by ProxyA when applying RtpProxyA. When ProxyB executes force_rtpproxy() this function will not modify the SDP since that line is present. If not, there will be no audio because RtpProxyA would be waiting for audio from RtpProxyB and vice versa (lock condition). ProxyB must be well configured, this means that since force_rtpproxy() didn't success on the incoming INVITE, it must no execute force_rtpproxy() on the 18X/2XX response from bob. For this, I use a bflag(RTPPROXY_SET) which only set to 1 if force_rtpproxy() succeded in the incoming INVITE, and only run force_rtpproxy() for responses from bob if that bflag is on. force_rtpproxy() returns TRUE (1) just in case the SDP was modified. Best regards. -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
10 feb 2009 kl. 13.10 skrev Iñaki Baz Castillo: 2009/2/10 Johansson Olle E o...@edvina.net: If both devices are on private IP's, there's going to be two RTP proxys involved if they're on different SIP networks. Each SIP service needs an RTP proxy for supporting their local users. Hi, I don't fully agree on it: alice --- (NAT A) --- ProxyA RtpProxyA --- ProxyB RtpProxyB --- (NAT B) --- bob In this case, when alice calls bob, ProxyA will apply RtpProxyA so the SDP will contain a public IP. Since ProxyB knows that bob is registered behind NAT, it will try to apply RtpProxyB but this will fail because the incoming SDP contains a line: a=nortpproxy:yes This line was added by ProxyA when applying RtpProxyA. When ProxyB executes force_rtpproxy() this function will not modify the SDP since that line is present. If not, there will be no audio because RtpProxyA would be waiting for audio from RtpProxyB and vice versa (lock condition). On the INVITE there's no need for ProxyB to allocate an rtpproxy, since the SDP already has public IP - fixed by Proxy A. ProxyB must be well configured, this means that since force_rtpproxy() didn't success on the incoming INVITE, it must no execute force_rtpproxy() on the 18X/2XX response from bob. For this, I use a bflag(RTPPROXY_SET) which only set to 1 if force_rtpproxy() succeded in the incoming INVITE, and only run force_rtpproxy() for responses from bob if that bflag is on. It should force RTPproxy on teh response from Bob, since Bob is a local user and the SDP includes a private IP. force_rtpproxy() returns TRUE (1) just in case the SDP was modified. Yes. /O smime.p7s Description: S/MIME cryptographic signature ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
2009/2/10 Johansson Olle E o...@edvina.net: alice --- (NAT A) --- ProxyA RtpProxyA --- ProxyB RtpProxyB --- (NAT B) --- bob In this case, when alice calls bob, ProxyA will apply RtpProxyA so the SDP will contain a public IP. Since ProxyB knows that bob is registered behind NAT, it will try to apply RtpProxyB but this will fail because the incoming SDP contains a line: a=nortpproxy:yes This line was added by ProxyA when applying RtpProxyA. When ProxyB executes force_rtpproxy() this function will not modify the SDP since that line is present. If not, there will be no audio because RtpProxyA would be waiting for audio from RtpProxyB and vice versa (lock condition). On the INVITE there's no need for ProxyB to allocate an rtpproxy, since the SDP already has public IP - fixed by Proxy A. No, that's not an excuse. RtpProxy must be applied in both the request and response. If a PSTN gateway calls a SIP user behind NAT, you must apply RtpProxy even if the incoming SDP has public address. ProxyB must be well configured, this means that since force_rtpproxy() didn't success on the incoming INVITE, it must no execute force_rtpproxy() on the 18X/2XX response from bob. For this, I use a bflag(RTPPROXY_SET) which only set to 1 if force_rtpproxy() succeded in the incoming INVITE, and only run force_rtpproxy() for responses from bob if that bflag is on. It should force RTPproxy on teh response from Bob, since Bob is a local user and the SDP includes a private IP. Not again, please re-read my explanation above :) In the example of a PSTN gateway calling a natted SIP user, if the proxy only applies RtpProxy in the user response then you will get asymmetric audio: user (NAT)RtpProxy Gateway --(RTP)--- -(RTP)-- -(RTP)-- So the RTP from the gateway will not arrive to the user since the NAT router will not allow it (there is not an existing UDP mapping to allow UDP traffic from the RtpProxy, but just from the Gateway address). So RtpProxy must be present in the request and response, then the NAT router mapping will work and allow incoming data from RtpProxy after the user sends RTP data to the RtpProxy. Am I wrong? -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
10 feb 2009 kl. 13.44 skrev Iñaki Baz Castillo: 2009/2/10 Johansson Olle E o...@edvina.net: alice --- (NAT A) --- ProxyA RtpProxyA --- ProxyB RtpProxyB --- (NAT B) --- bob In this case, when alice calls bob, ProxyA will apply RtpProxyA so the SDP will contain a public IP. Since ProxyB knows that bob is registered behind NAT, it will try to apply RtpProxyB but this will fail because the incoming SDP contains a line: a=nortpproxy:yes This line was added by ProxyA when applying RtpProxyA. When ProxyB executes force_rtpproxy() this function will not modify the SDP since that line is present. If not, there will be no audio because RtpProxyA would be waiting for audio from RtpProxyB and vice versa (lock condition). On the INVITE there's no need for ProxyB to allocate an rtpproxy, since the SDP already has public IP - fixed by Proxy A. No, that's not an excuse. RtpProxy must be applied in both the request and response. If a PSTN gateway calls a SIP user behind NAT, you must apply RtpProxy even if the incoming SDP has public address. Not in the INVITE sdp - the device behind the NAT can always send to a public IP address, right? ProxyB must be well configured, this means that since force_rtpproxy() didn't success on the incoming INVITE, it must no execute force_rtpproxy() on the 18X/2XX response from bob. For this, I use a bflag(RTPPROXY_SET) which only set to 1 if force_rtpproxy() succeded in the incoming INVITE, and only run force_rtpproxy() for responses from bob if that bflag is on. It should force RTPproxy on teh response from Bob, since Bob is a local user and the SDP includes a private IP. Not again, please re-read my explanation above :) In the example of a PSTN gateway calling a natted SIP user, if the proxy only applies RtpProxy in the user response then you will get asymmetric audio: user (NAT)RtpProxy Gateway --(RTP)--- -(RTP)-- -(RTP)-- So the RTP from the gateway will not arrive to the user since the NAT router will not allow it (there is not an existing UDP mapping to allow UDP traffic from the RtpProxy, but just from the Gateway address). The gateway will (in teh case of Asterisk) listen to the audio coming from the user and change to the port and IP we're receiving audio from. That way, we'll have symmetric audio and will bypass the NAT. So RtpProxy must be present in the request and response, then the NAT router mapping will work and allow incoming data from RtpProxy after the user sends RTP data to the RtpProxy. Am I wrong? We are mixing cases here. One case is a gateway scenario, where the RTP proxy isn't really needed, since the gateway may take care of it by itself, provided that the gateway is on a public IP. If you have two users both behind NAT, each user applies an RTP proxy to the incoming audio stream, not the outbound stream. /O smime.p7s Description: S/MIME cryptographic signature ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
2009/2/10 Johansson Olle E o...@edvina.net: No, that's not an excuse. RtpProxy must be applied in both the request and response. If a PSTN gateway calls a SIP user behind NAT, you must apply RtpProxy even if the incoming SDP has public address. Not in the INVITE sdp - the device behind the NAT can always send to a public IP address, right? Yes, but it will not receive it if the incoming RTP comes from a different address (the RtpProxy). The NAT router will not allow that incoming traffic since there hasn't been a NAT mapping before (the client doesn't send its RTP to RtpProxy but to the gateway). user (NAT)RtpProxy Gateway --(RTP)--- -(RTP)-- -(RTP)-- So the RTP from the gateway will not arrive to the user since the NAT router will not allow it (there is not an existing UDP mapping to allow UDP traffic from the RtpProxy, but just from the Gateway address). The gateway will (in teh case of Asterisk) listen to the audio coming from the user and change to the port and IP we're receiving audio from. That way, we'll have symmetric audio and will bypass the NAT. Ahhh, but that's Comedia mode (available in Asterisk, SEMS, some Cisco gateways...) I already mention decives supporting Comedia mode in my first mail to this thread :) So RtpProxy must be present in the request and response, then the NAT router mapping will work and allow incoming data from RtpProxy after the user sends RTP data to the RtpProxy. Am I wrong? We are mixing cases here. One case is a gateway scenario, where the RTP proxy isn't really needed, since the gateway may take care of it by itself, provided that the gateway is on a public IP. If you have two users both behind NAT, each user applies an RTP proxy to the incoming audio stream, not the outbound stream. In this point I don't agree again. What you suggest it: alice --- (NAT A) --- ProxyA RtpProxyA --- ProxyB RtpProxyB --- (NAT B) --- bob So: - alice calls bob. ProxyA applies RtpProxyA to the INVITE. - ProxyB receives the INVITE and doesn't apply RtpProxyB since address in SDP is public (set by ProxyA). - bob replies 200 OK. - ProxyB applies RtpProxyB to the response. - The reply arrives to ProxyA which doesn't apply RtpProxyA since the SDP address is public (set by ProxyB). So we get the following RTP flow (please use fixed size fonts): alice (NAT A) RtpProxyA RtpProxyB(NAT B) bob --- -- - - RTP from alice will not arrive to bob since it will be rejected by NAT B router (no existing mapping). - RTP from bob will not arrive to alice since it will be rejected by NAT A router (no existing mapping). - No audio at all. -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
Hi Olle, Johansson Olle E wrote: 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo: 2009/2/10 julianok...@gmail.com: You don't know if RtpProxy should be running, does it mean you are trying to use it or not? I don't want to spend time inspecting what you want to do by reading your config, sorry. Yeah, I'm trying not to run RTPProxy. After more testing, I'm thinking I may need to. You cannot decide if you need RtpProxy or not based on testing, it's pure theory: A RTP proxy is NOT needed when (assuming the proxy has in the public internet): - Both caller and callee have public IP or use STUN. - Both caller and callee are in the *SAME* private LAN. - The caller is in a private LAN and the callee has public IP and supports Comedia mode (typical in some media servers and gateways). - The callee is in a private LAN and the caller has public IP and supports Comedia mode. A RTP proxy is needed when: - Caller is in private LAN (with no STUN) and callee in public internet (and not supporting Comedia). - Caller and callee are in different private LAN's with no STUN. I would like to add that it's the device that can't receive audio that needs the RTP proxy to get incoming audio. If both devices are on private IP's, there's going to be two RTP proxys involved if they're on different SIP networks. Each SIP service needs an RTP proxy for supporting their local users. To simplify: - If my user is on a private IP and sends an INVITE, add RTP proxy handling to the INVITE - If my user receives a call and sends a 200 OK, add RTP proxy handling to the 200 OK This logic is simple but not efficientTheoretically, if a call has already a leg in public net, there is not need for a media relay for traversing the nat. The only requirement is that all the devices to support symmetric media (comedia support). So, after the caller proxy forced RTPproxy, the callee should not do the same because the SDP already have a public IP, the nat traversal works even if the callee is behind a nat. Regards, Bogdan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio with AudioCodes Mediant 2000 and NAT
Thanks all. I'll check to see if the AudioCodes gateway does have comedia support. That clarifies some half baked NAT/RTP knowledge in my head. - Julian On 2/10/09, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Olle, Johansson Olle E wrote: 10 feb 2009 kl. 12.25 skrev Iñaki Baz Castillo: 2009/2/10 julianok...@gmail.com: You don't know if RtpProxy should be running, does it mean you are trying to use it or not? I don't want to spend time inspecting what you want to do by reading your config, sorry. Yeah, I'm trying not to run RTPProxy. After more testing, I'm thinking I may need to. You cannot decide if you need RtpProxy or not based on testing, it's pure theory: A RTP proxy is NOT needed when (assuming the proxy has in the public internet): - Both caller and callee have public IP or use STUN. - Both caller and callee are in the *SAME* private LAN. - The caller is in a private LAN and the callee has public IP and supports Comedia mode (typical in some media servers and gateways). - The callee is in a private LAN and the caller has public IP and supports Comedia mode. A RTP proxy is needed when: - Caller is in private LAN (with no STUN) and callee in public internet (and not supporting Comedia). - Caller and callee are in different private LAN's with no STUN. I would like to add that it's the device that can't receive audio that needs the RTP proxy to get incoming audio. If both devices are on private IP's, there's going to be two RTP proxys involved if they're on different SIP networks. Each SIP service needs an RTP proxy for supporting their local users. To simplify: - If my user is on a private IP and sends an INVITE, add RTP proxy handling to the INVITE - If my user receives a call and sends a 200 OK, add RTP proxy handling to the 200 OK This logic is simple but not efficientTheoretically, if a call has already a leg in public net, there is not need for a media relay for traversing the nat. The only requirement is that all the devices to support symmetric media (comedia support). So, after the caller proxy forced RTPproxy, the callee should not do the same because the SDP already have a public IP, the nat traversal works even if the callee is behind a nat. Regards, Bogdan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
