17 Jul
2004
17 Jul
'04
2:09 a.m.
Use SER 0.8.12 stable release, enabled nathelper+rtpproxy for NAT traversal, forward
1(xxx)xxx-xxxx to SIp termiantion gateway, when the call was connected, PSTN gateway send
200 OK back, sip client ( behind NAT ) response with ACK ( which has branch value in Via
head ), but when SER forward the ACK back to PSTN gateway, in Via header it includes
branch=0, PSTN gateway refuse this ACk because it think the branch id is invalid, so call
was dropped after 30- 60 seconds, what's wrong with that? I really appreciate if you
met such problems before, thanks, and have a nice day.
Here is captured message between pstn gateway and ser:
SIP MESSAGE 4 65.22.14.3:42326(1) -> 182.156.33.10:5060(2)
UDP Frame 13 10/Jul/04 13:29:33.6715 TimeFromPreviousSipFrame=3.4065
TimeFromStart=6.3374
SIP/2.0 200 OK
Call-ID: 3164823746(a)192.168.0.102
From: <sip:2103334444@182.156.33.10;user=phone>;tag=1842950071
To: <sip:021445333321@182.156.33.10;user=phone>;tag=17810
Content-Length: 215
Content-Type: application/sdp
CSeq: 1 INVITE
Via: SIP/2.0/UDP 182.156.33.10;branch=z9hG4bK2681.4c495f05.0,SIP/2.0/UDP
192.168.0.102:5060;rport=64069;received=65.33.22.6
Contact: sip:19727925475@65.22.14.3:5060
Record-Route: <sip:021445333321@182.156.33.10;ftag=1842950071;lr=on>
SIP MESSAGE 5 182.156.33.10:5060(2) -> 65.22.14.3:42326(1)
UDP Frame 23 10/Jul/04 13:29:33.7641 TimeFromPreviousSipFrame=0.0926
TimeFromStart=6.4300
ACK sip:19727925475@65.22.14.3:42326 SIP/2.0
Max-Forwards: 10
Record-Route: <sip:021445333321@182.156.33.10;ftag=1842950071;lr=on>
Via: SIP/2.0/UDP 182.156.33.10;branch=0
Via: SIP/2.0/UDP 192.168.0.102:5060;rport=64069;received=65.33.22.6
From: <sip:2103334444@182.156.33.10;user=phone>;tag=1842950071
To: <sip:021445333321@182.156.33.10;user=phone>;tag=17810
Call-ID: 3164823746(a)192.168.0.102
CSeq: 1 ACK
User-Agent: Cisco ATA v2.15 ata18x (020927a)
Content-Length: 0
Here is the configuration file:
debug=0
fork=yes
log_stderror=yes
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=8
listen=182.156.33.10
fifo="/tmp/ser_fifo"
loadmodule "/usr/lib/ser/modules/nathelper.so"
loadmodule "/usr/lib/ser/modules/mysql.so"
loadmodule "/usr/lib/ser/modules/sl.so"
loadmodule "/usr/lib/ser/modules/tm.so"
loadmodule "/usr/lib/ser/modules/rr.so"
loadmodule "/usr/lib/ser/modules/maxfwd.so"
loadmodule "/usr/lib/ser/modules/usrloc.so"
loadmodule "/usr/lib/ser/modules/registrar.so"
loadmodule "/usr/lib/ser/modules/textops.so"
loadmodule "/usr/lib/ser/modules/uri.so"
loadmodule "/usr/lib/ser/modules/auth.so"
loadmodule "/usr/lib/ser/modules/auth_radius.so"
loadmodule "/usr/lib/ser/modules/acc.so"
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "db_mode", 2)
modparam("rr", "enable_full_lr", 1)
modparam("auth_radius", "radius_config",
"/etc/radiusclient/radiusclient.conf")
modparam("auth_radius", "service_type", 15)
modparam("acc", "service_type", 15)
modparam("acc", "radius_config",
"/etc/radiusclient/radiusclient.conf")
modparam("acc", "log_level", 2)
modparam("acc", "radius_flag", 1)
modparam("acc", "radius_missed_flag", 9)
modparam("nathelper", "natping_interval", 10)
route{
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;
};
setflag(1); /* Radius Accouting */
loose_route();
record_route();
if (search("(a)192.168.*") || search("(a)10.*") ||
search("(a)172.16.*")) {
setflag(2);
force_rport();
fix_nated_contact();
};
/* For Radius Accounting */
if (method=="INVITE") {
log(1, "INVITE: Radius Accounting\n");
setflag(1); /* Radius Accouting */
if (isflagset(2)) {
force_rtp_proxy();
};
t_on_reply("1");
};
if (method=="MESSAGE") {
log(1, "MESSAGE: Radius Accounting\n");
setflag(1); /* Radius Accouting */
};
if (method=="BYE" || method=="CANCEL") {
log (1, "BYE or CANCEL: Radius Accounting\n");
setflag(1); /* Radius Accouting */
};
if (uri==myself) {
if (method=="REGISTER") {
if (!radius_www_authorize("")) {
log(1, "REGISTER: Radius Challenging User\n");
www_challenge("", "0");
break;
};
save("location");
break;
};
lookup("aliases");
if (uri=~"sip:1[0-9][0-9][0-9]*@.*") {
t_relay_to_udp("65.22.14.3", "5060");
break;
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
break;
};
};
setflag(1);
if (!t_relay()) {
sl_reply_error();
};
}
onreply_route[1] {
if ( ((status=~"2[0-9][0-9]")||(status=~"183")) &&
(search("192.168.*") || search("(a)10.*") ||
search("172.16.*") )) {
fix_nated_contact();
force_rtp_proxy();
};
}
--
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as…
17 Jul
17 Jul
9:58 a.m.
On Jul 16, 2004 at 19:09, ks lf <ksabc(a)lycos.com> wrote:
Use SER 0.8.12 stable release, enabled
nathelper+rtpproxy for NAT traversal, forward 1(xxx)xxx-xxxx to SIp termiantion gateway,
when the call was connected, PSTN gateway send 200 OK back, sip client ( behind NAT )
response with ACK ( which has branch value in Via head ), but when SER forward the ACK
back to PSTN gateway, in Via header it includes branch=0, PSTN gateway refuse this ACk
because it think the branch id is invalid, so call was dropped after 30- 60 seconds,
what's wrong with that? I really appreciate if you met such problems before, thanks,
and have a nice day.
What kind of gateway do you use? Seems really too picky (an ACK to a 200
Ok is not part of the transaction anyway, and checking for branch
magic numbers and rejecting the message if not present is really
exagerated). Does it work with ACK without branch in Via (e.g. you can
tests this by connecting directly the Cisco ATA to the gateway, without
going through the proxy).
To workarround this try to add to ser.cfg
syn_branch=0
(this would force full branch computation even for stateless forwards,
like the ACK to 200 Ok case).
Andrei
11:47 a.m.
At 09:58 AM 7/17/2004, Andrei Pelinescu-Onciul wrote:
On Jul 16, 2004 at 19:09, ks lf <ksabc(a)lycos.com>
wrote:
> Use SER 0.8.12 stable release, enabled nathelper+rtpproxy for NAT traversal, forward
1(xxx)xxx-xxxx to SIp termiantion gateway, when the call was connected, PSTN gateway send
200 OK back, sip client ( behind NAT ) response with ACK ( which has branch value in Via
head ), but when SER forward the ACK back to PSTN gateway, in Via header it includes
branch=0, PSTN gateway refuse this ACk because it think the branch id is invalid,
I don't know if this is the reason why the gateway denies the ACK, but if so,
you should submit a trouble ticket to the gateway vendor. According to RFC3261,
ACK for positive replies is a separate transaction and there is no guarantee
that it would have the same branch id. People who have difficults to understand
that typically get the "aha" effect when they see a scenario with multiple
proxy
servers as follows:
UAC PROXY1 PROXY2 UAS
(record-routing) (no rr-ing)
INVITE -----------------> ----------------> -------------->
ACK -----------------> ------------------------------------->
in this scenario, only proxy 1 record routes, i.e., subsequent requests such
as ACK will not visit proxy2. Consequently, proxy2 cannot generate the same
branch ID as it did for proxy1. UAS will thus see proxy1's branch in the ACK,
which is different from proxy2's branch in the original INVITE.
Tell the vendor to match ACKs _DIALOG-WISE_.
-jiri
7412
days inactive
7412
days old
2 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Jiri Kuthan -
ks lf