At 07:28 PM 11/6/2003, Glenn Dalgliesh wrote:
Problem: One-way audio when forwarding that must go
thru another negociate SER server before reaching Endpoint.
I have gotten calls from SER with nathelper and rtp proxy to work reliably btw phones
registered with SER box but when I trie to forward the call to a EXT on another SER box
not running nathelper with register client with public ip's I get one way audio. After
doing some snooping it appears that one direction of the rtp stream end up directed at the
rtpproxy and the other direction goes directly to the phone. I know the sip messages must
not be getting rewriten properly but I can't seem to get it right.
this is the route section of my ser.cfg
Thanks
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");
break;
};
if (msg:len >= max_len ) {
sl_send_reply("513", "Message too big");
break;
};
# things we think we want to do for every request;
# this box is dedicated to NAT only behavior
record_route();
force_rport();
fix_nated_contact();
# loose-route processing
if (loose_route()) {
t_relay();
break;
};
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
if (method=="REGISTER") {
save("location");
break;
};
if (uri=~"^sip:[7][0][0][1]@") {
rewritehost("sipdemo.xxxx.net");
fix_nated_sdp("3");
force_rtp_proxy();
a possible explanation is you dont setup t_on_reply here, like you
do it bellow. -jiri
t_relay();
break;
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
break;
};
};
if (method=="INVITE") {
# This appears to make the called party's audio work
fix_nated_sdp("3");
force_rtp_proxy();
# Call the onreply_route? This appears to link calling and called
party's audio together
t_on_reply("1");
};
# forward to current uri now; use stateful forwarding; that
# works reliably even if we forward from TCP to UDP
if (!t_relay()) {
sl_reply_error();
};
}
# This appears to make calling party's audio work
onreply_route[1] {
if (status=~"2[0-9][0-9]") {
force_rport();
fix_nated_contact();
fix_nated_sdp("3");
force_rtp_proxy();
};
}
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan
http://iptel.org/~jiri/