9 Mar
2006
9 Mar
'06
8:04 p.m.
Looks like forward includes relay in it. And by putting force_rtpproxy
AFTER forward you does not give it a chance :-) on_reply route is also
MUST be there.
________________________________
From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On
Behalf Of Script Head
Sent: Thursday, March 09, 2006 12:59 PM
To: users(a)openser.org
Subject: Re: [Users] forcing rtpproxy on a call
Thank you guys, it's working now.
Apparently, rewritehostport("<ip>:<port>") works great with
rptproxy
while forward does exactly that, forwards the call to the destination
bypassing the force_rtp_proxy request. This should be documented
somewhere.
ScriptHead
On 3/9/06, Vitaly Nikolaev <vnikolaev(a)intermedia.net> wrote:
1. I never used forward, see my example, I do not know if it
actually relay call or not
2. if you do not have NAT between client and server you do not need
force_rport, and try to avoid any nat_uac_test, etc if you are actually
working on private ips without nat
3. you MUST enable proxy also for reply
route[x] {
.....
force_rtp_proxy();
t_on_reply("1");
rewritehostport("x.x.x.x:5060");
if (!t_relay()) {
sl_reply_error();
};
}
onreply_route[1] {
if (!(status=~"183" || status=~"200"))
break;
force_rtp_proxy("");
}
________________________________
From: users-bounces(a)openser.org [mailto: users-bounces(a)openser.org
<mailto:users-bounces@openser.org> ] On Behalf Of Script Head
Sent: Wednesday, March 08, 2006 6:29 PM
To: users(a)openser.org
Subject: [Users] forcing rtpproxy on a call
Hello everyone,
I am trying to debug why my rtpproxy isn't working. I have the following
setup, on my LAN.
softphone (192.168.1.100) -> openser/rtpproxy ( 192.168.1.10
<http://192.168.1.10> ) -> asterisk (192.168.1.12)
The rtpproxy is running and I see commands flying thru it.
the following route works
if(method=="INVITE") {
if(uri=~"^sip:[0-9]{6}1[0-9]*{10}@") {
forward(192.168.1.12,5060);
};
}
when I replace it with this route
if(method=="INVITE") {
if(uri=~"^sip:[0-9]{6}1[0-9]*{10}@") {
forward(192.168.1.12,5060);
};
force_rport();
force_rtp_proxy();
}
I get dead air while asterisk logs show that my test message is playing.
How should I proceed to debug this?
ScriptHead
10 Mar
10 Mar
1:44 a.m.
New subject: [Users] forcing rtpproxy on a call
Now that my rtpproxy actually passes traffic I stumbled on another problem.
When the called party hangs up the call (asterisk command Hangup()) the soft
phone remains connected. Yet, when I click the Hangup button on the
softphone, SER receives BYE messages.
On 3/9/06, Vitaly Nikolaev <vnikolaev(a)intermedia.net> wrote:
Looks like forward includes relay in it. And by putting force_rtpproxy
AFTER forward you does not give it a chance J on_reply route is also MUST
be there.
------------------------------
*From:* users-bounces(a)openser.org [mailto:users-bounces@openser.org] *On
Behalf Of *Script Head
*Sent:* Thursday, March 09, 2006 12:59 PM
*To:* users(a)openser.org
*Subject:* Re: [Users] forcing rtpproxy on a call
Thank you guys, it's working now.
Apparently, rewritehostport("<ip>:<port>") works great with
rptproxy while
forward does exactly that, forwards the call to the destination bypassing
the force_rtp_proxy request. This should be documented somewhere.
ScriptHead
On 3/9/06, *Vitaly Nikolaev* <vnikolaev(a)intermedia.net> wrote:
1. I never used forward, see my example, I do not know if it
actually relay call or not
2. if you do not have NAT between client and server you do not need
force_rport, and try to avoid any nat_uac_test, etc if you are actually
working on private ips without nat
3. you MUST enable proxy also for reply
route[x] {
…..
force_rtp_proxy();
t_on_reply("1");
rewritehostport("x.x.x.x:5060");
if (!t_relay()) {
sl_reply_error();
};
}
onreply_route[1] {
if (!(status=~"183" || status=~"200"))
break;
force_rtp_proxy("");
}
------------------------------
*From:* users-bounces(a)openser.org [mailto: users-bounces(a)openser.org] *On
Behalf Of *Script Head
*Sent:* Wednesday, March 08, 2006 6:29 PM
*To:* users(a)openser.org
*Subject:* [Users] forcing rtpproxy on a call
Hello everyone,
I am trying to debug why my rtpproxy isn't working. I have the following
setup, on my LAN.
softphone (192.168.1.100) -> openser/rtpproxy ( 192.168.1.10) -> asterisk
(192.168.1.12)
The rtpproxy is running and I see commands flying thru it.
the following route works
if(method=="INVITE") {
if(uri=~"^sip:[0-9]{6}1[0-9]*{10}@") {
forward(192.168.1.12,5060);
};
}
when I replace it with this route
if(method=="INVITE") {
if(uri=~"^sip:[0-9]{6}1[0-9]*{10}@") {
forward(192.168.1.12,5060);
};
force_rport();
force_rtp_proxy();
}
I get dead air while asterisk logs show that my test message is playing.
How should I proceed to debug this?
ScriptHead
10:35 a.m.
New subject: [Users] forcing rtpproxy on a call
Hi,
do you see on net any BYE generated by asterisk, going to openser?
regards,
bogdan
Script Head wrote:
Now that my rtpproxy actually passes traffic I
stumbled on another
problem. When the called party hangs up the call (asterisk command
Hangup()) the soft phone remains connected. Yet, when I click the
Hangup button on the softphone, SER receives BYE messages.
4:16 p.m.
New subject: [Users] forcing rtpproxy on a call
That's the thing, Asterisk definetly sends a BYE but OpenSER doesn't receive
it. It doesn't happen if the call goes thru the RTPproxy or just gets
redirected via rewritehostport.
4:33 p.m.
New subject: [Users] forcing rtpproxy on a call
The best way to prove Your point to capture the traffic and make some
analisys
Didnt You have NGREP anywhere? Use it on the two output interfaces/ports
and see what and where are they sending the packets.
Tell us what You find from this
Regards,
Edson
PS: TCPDUMP will also work, but is more complicated than NGREP.
_____
From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On Behalf
Of Script Head
Sent: sexta-feira, 10 de março de 2006 11:16
To: Bogdan-Andrei Iancu
Cc: users(a)openser.org
Subject: Re: [Users] forcing rtpproxy on a call
That's the thing, Asterisk definetly sends a BYE but OpenSER doesn't receive
it. It doesn't happen if the call goes thru the RTPproxy or just gets
redirected via rewritehostport.
6836
days inactive
6837
days old
4 comments
4 participants
participants (4)
-
Bogdan-Andrei Iancu -
Edson -
Script Head -
Vitaly Nikolaev