Hi, Nick!
In the traces you sent, it seems that the callee's RTP traffic doesn't
reach the media relay server. This is most likely because the RTPProxy
is behind NAT. In this case you have to double check two things:
* if the SDP is properly changed for the INVITEs and 200OKs
* if the media ports are properly forwarded to RTPProxy.
The second thing I noticed is that you use both engage_rtp_proxy and
rtpproxy_* functions. I don't think this is such a good idea to mix
them. Anyway, in your script, engage_rtp_proxy doesn't have any effect
because you are not supposed to call it on sequential requests, only on
initial request. So you can simply delete it.
Regards,
--
Răzvan Crainea
OpenSIPS Developer
On 12/23/2011 05:25 AM, Nick Khamis wrote:
Hello Everyone,
I am testing a simple case where we have:
UC--->OpenSIPS---->ITSP Gateway
The UC and OpenSIPS are on the same network behind a router. The
related parts of my config look like:
route{
.....
if (is_method("INVITE")&& has_totag())
engage_rtp_proxy("ie","127.0.0.1");
.....
}
route[1] {
if (is_method("INVITE")) {
xlog("Start Call for route [ fu=$fu/ tu=$tu /ru=$ru/ ci=$ci]");
prefix("00111");
rewritehostport("itsp.serviceprovider.com:5060");
if (has_body("application/sdp")) {
if (rtpproxy_offer()) t_on_reply("1");
else t_on_reply("2");
}
t_on_branch("2");
t_on_failure("1");
}
if (is_method("ACK")&& has_body("application/sdp")) rtpproxy_answer();
if (!t_relay()) {
sl_reply_error();
}
exit;
}
onreply_route[1] {
xlog("incoming reply\n");
if (has_body("application/sdp")) rtpproxy_answer();
exit;
}
onreply_route[2] {
xlog("incoming reply\n");
if (has_body("application/sdp")) rtpproxy_offer();
exit;
}
Everything seems to be starting fine except there is no audio both
ways. RTPProxy is started using the following:
./rtpproxy -s udp:127.0.0.1:7789 -l 192.168.2.102 -m 10000 -M 20000 -u
root root -F -f -d INFO LOG_LOCAL0
INFO:main: rtpproxy started, pid 2185
INFO:handle_command: new session
[email protected], tag D6D9E7BD-BC7B6732;1
requested, type strong
INFO:handle_command: new session on a port 11420 created, tag
D6D9E7BD-BC7B6732;1
INFO:handle_command: pre-filling caller's address with 192.168.2.11:2222
INFO:handle_command: lookup on ports 11420/15872, session timer restarted
INFO:handle_command: pre-filling callee's address with 95.211.119.251:36076
INFO:process_rtp: session timeout
INFO:remove_session: RTP stats: 0 in from callee, 326 in from caller,
326 relayed, 0 dropped
INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0
relayed, 0 dropped
INFO:remove_session: session on ports 11420/15872 is cleaned up
A short sip trace:
4.714356 192.168.2.11 -> 192.168.2.102 SIP/SDP Request: INVITE
sip:[email protected];user=phone, with session
description
4.790394 192.168.2.102 -> 192.168.2.11 SIP Status: 100 Giving a try
4.802400 192.168.2.102 -> 202.163.224.113 DNS Standard query A
itsp.serviceprovider.com
4.982490 202.163.224.113 -> 192.168.2.102 DNS Standard query
response A 93.221.112.231
4.982490 192.168.2.102 -> 93.221.112.231 SIP/SDP Request: INVITE
sip:[email protected]:5060;user=phone, with session
description
5.070534 93.221.112.231 -> 192.168.2.102 SIP Status: 100 Trying
incoming reply
6.339168 93.221.112.231 -> 192.168.2.102 SIP/SDP Status: 183 Session
Progress, with session description
6.339168 192.168.2.102 -> 192.168.2.11 SIP/SDP Status: 183 Session
Progress, with session description
6.467232 192.168.2.11 -> 192.168.2.102 RTP PT=ITU-T G.711 PCMU,
SSRC=0x7E7F31B9, Seq=38666, Time=2196142936, Mark
As mentioned earlier the UC and OpenSIPS+RTPProxy are behind a router
with ports 5060, and 10000-20000 being forwarded to the OpenSIPS
server.
I even tried putting the server in the DMZ, but still to no avail.
Thanks in Advance, and Happy Holidays,
Nick
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
