8 Jun
2004
8 Jun
'04
4:48 p.m.
Hi all,
I am having problem with call onhold on symmetric NAT softphone which have
affected the conferencing features. when I compare the sip-message, I
realise that the branch code is different and when they do a re-invite to
restablish the call, the m=audio XXXX port changes, please advice what can
be done. Does the branch affect?
If i didnt start rtpproxy, my call onhold works fine but when rtpproxy is
started, the call onhold is not working.I need the rtpproxy for symmetric
network. Please help....
my config file is below.
Regards,
shirley
-----Original Message-----
From: Shirley Toh
Sent: Monday, June 07, 2004 9:00 PM
To: Serusers (E-mail)
Subject: RTPPROXY problem with cal forward and symmetric
Hi all,
I am having this problem with ./rtpproxu command.
Before I start this command, my call forward and conference works fine
with PC to PC and PC to PSTN but users behind symmetric NAT have no audio
when connected.
When I started the command, the scenario go the other way round, symmetric
is working but my call forward and conference is not working. I have
attached my cfg file.
Please help and thank you in advance!!!
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;
};
#!! Nathelper
if (nat_uac_test("3")){
if (method == "REGISTER" || !search("^Record-Route:")){
log("LOG:Someone trying to register from private IP,
rewriting\n");
fix_nated_contact(); # Rewtite contact with source
IP of signalling
if(method== "INVITE"){
fix_nated_sdp("1"); # Add direction-active
to SDP
};
force_rport();
setflag(6);
};
}else{
fix_nated_contact();
};
# 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
record_route();
# 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:019[0-9]+@myserver.com") {
strip(1);
rewritehostport("1.2.3.4:5060");
t_relay();
break;
}
if (method=="INVITE") {
fix_nated_sdp("3");
append_hf("P-hint:Invite");
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("", "Connecting");
break;
};
};
if (method=="ACK"){
sl_send_reply("", "ACK");
break;
};
if (isflagset(6)){
force_rtp_proxy();
append_hf("P-hint:Flag6");
}else{
force_rtp_proxy();
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();
break;
};
}
# all incoming replies for t_onrepli-ed transactions enter here
onreply_route[1] {
sdp_mangle_port("-12000");
if (isflagset(6) && status=~"2[0-9][0-9]"){
append_hf("First Route");
fix_nated_contact();
fix_nated_sdp("1");
force_rtp_proxy();
} else if (status=~"2[0-9][0-9]"){
if (uri=~"sip:019[0-9]+@myserver.com") {
append_hf("019");
fix_nated_contact();
fix_nated_sdp("3");
}
else{
append_hf("2nd Route");
fix_nated_contact();
fix_nated_sdp("2");
fix_nated_sdp("3");
force_rtp_proxy();
}
};
}
Regards,
Shirley