Dear Paul:
I am a new user of SER sip. And would you please tell me an explain
about what the RPID is??
I want to control the call to PSTN with B2BUA of vovida or Asterisk.
Best Regard
Charles
On Wed, 23 Feb 2005 10:33:26 -0500, Java Rockx <javarockx(a)gmail.com> wrote:
> Vitaly,
>
> I believe you are correct that RPID is only helpful during SIP->PSTN calls.
>
> I'm not real familiar with B2BUA, but if I were to introduce one in to
> my system, does that mean I need to have all the RTP traffic pass
> through my network as well, or does the B2BUA only deal with SIP
> messaging?
>
> Regards,
> Paul
>
> On Wed, 23 Feb 2005 10:14:18 -0500, Vitaly Nikolaev
> <vitaly(a)voipsonic.com> wrote:
> >
> > The answer is B2BUA
> >
> > There actually two ways,
> >
> > First is b2bua which is nice (for me ok.. I like it :)
> >
> > Second if you assign the CallerID number to device.. the real callerid, (for
> > example in my network we use some fake numbers into devices and then change
> > it do real callerid (did) in b2bua), then some devices, for example SIPURA,
> > can send Anonymous as name in From and Contact and some GWs, will use it and
> > hide callerid on outgoing call.
> >
> > And third:
> >
> > And there are also Remote-Party-Id: field in SIP that partially supported by
> > SER and supported by most of GW and carriers, and that is probably RIGHT way
> > to do that.
> >
> > When PSTN GW sends call to outside of ur network, it no just skip callerid,
> > u can do it but it is wrong, it make it private, so usual ppl will not see
> > it but for example 911 and some toll free subscriber will see. That right
> > way and that how everybody should do cli blocking.
> >
> > What is wrong in this method is that if you call goes from SIP to SIP and
> > you use as me fake CLI on devices, customers will see fake numbers because
> > as far as I know SIP devices does not support RPID (please correct me if I
> > am wrong) so in my case I will have to use combination of N1 and N3..
> >
> >
> > -----Original Message-----
> > From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
> > Behalf Of Java Rockx
> > Sent: Wednesday, February 23, 2005 7:20 AM
> > To: Klaus Darilion
> > Cc: serusers(a)lists.iptel.org
> > Subject: Re: [Serusers] Manipulate from_uri
> >
> > Klaus,
> >
> > I realize that RFC3261 says do not modify the From header, however, my
> > question is this;
> >
> > When making SIP-to-SIP calls between two subscribers on the same SIP
> > proxy, how can one implement Caller ID Block when RPID is not usually
> > honored by SIP UAs - since this is really for PSTN gateways?
> >
> > It seems that altering the From header in this case is the only
> > option. Have I missed something?
> >
> > Regards,
> > Paul
> >
> > On Wed, 23 Feb 2005 12:00:14 +0100, Klaus Darilion
> > <klaus.mailinglists(a)pernau.at> wrote:
> > > Hi Mik!
> > >
> > > Do not modify the From: or To: URI - this is not allowed (RFC 3261) and
> > > will cause problems.
> > >
> > > regards,
> > > klaus
> > >
> > > Mik Cheez wrote:
> > > > Since I'm able to modify the URI for relaying, I would assume there
> > > > would be a way to modify the FROM_URI as well. Has anyone managed to do
> > > > this with SER acting as a proxy? Any other possible avenues to modify
> > > > the CALLID?
> > > >
> > > > Best regards
> > > >
> > > > _______________________________________________
> > > > Serusers mailing list
> > > > serusers(a)lists.iptel.org
> > > > http://lists.iptel.org/mailman/listinfo/serusers
> > > >
> > > >
> > >
> > > _______________________________________________
> > > Serusers mailing list
> > > serusers(a)lists.iptel.org
> > > http://lists.iptel.org/mailman/listinfo/serusers
> > >
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> >
> >
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
Hi
Just trying to debug why some calls work and other dont, I have 2 setups,
in both the UA is xlite , and is natted in both cases...however the
routers differ in each case.
Now I am running mediaproxy, when I debug ser, in one setups the contact
header which is displayed using xlog, shows the external IP address of
the router, in the other it does not, this happens after I have passed
the fix_contact setting in ser.cfg.
The one where it is fixed , allows me to listen to voicemail prompt from
asterisk without any problems, the other...no sound.
The clarification I need is this..
1. Mediaproxy solves symmetric NAT problems with ease..Y/N ?
2. For asymmetric stuff you need to add the clients to sip/rtp-asymmetric
files Y/N ?
3 If Yes the the client in this case is xlite...which is not really the
asymmetric part, its the router in the middle is it not ?
4. If I place slite in the file, will it not then affect the symmetric
xlite also.
Now if all this fails, can I on the xlite...which seems to be behind the
asymmetric setup, use STUN server, if yes, then the mediaproxy I guess
will not get called, or should it.....or is it better to map the
port/pathsin the router itself.
As a last question, if I wanted to determine what type of NATting a
device did, or I needed to debug a customers setup, whats the easiest way
tks
Iqbal
Raymond Chen writes:
> Anyway to put the PSTN gateway prefix into gw table?
no. gw table contains properties of gateways and routing info is in lcr
table.
-- juha
I installed the ser in Redhat 9.0. I use ngrep to capture the
packet.Sometime I got the bad UDP packet send from ser. The following is an
example(210.192.101.193 is the ser installed), before MESSAGE sip there are
illeagal chars (maybe due to the udp size limit?):
U 210.192.101.193:80 -> 218.25.90.134:31500 19036@0:1480
.P{.....MESSAGE sip:lumy1314@218.25.90.134:31500 SIP/2.0..Call-ID: 0f9
ffc6b4dbc35dd8cf153975330c83e@210.192.101.20..CSeq: 1 MESSAGE..From: "
miphone" <sip:multichat@sip.miphone.cn:20000;transport=udp>;tag=160203
74..To: <sip:lumy1314@dododoo.com>..Via: SIP/2.0/UDP 210.192.101.193:8
0;branch=z9hG4bKacb8.7ed584b7.0..Via: SIP/2.0/UDP 210.192.101.20:20000
;branch=z9hG4bK42e5063b387e084e01f8119c4491d60e..Max-Forwards: 69..Con
tent-Type: text/x-miphone-multichat..Content-Length: 995..P-hint: usrl
oc applied....<?xml version="1.0" encoding="UTF-8"?>.<miphone>.<comman
d type="add user">.<from>sip:server</from>.<to>lumy1314(a)dododoo.com</t
o>.<commandcontent>.<roomid>38563504</roomid>.<sipaddr>hxl(a)email.com.c
n</sipaddr>.<name>tuhxl-1</name>.<sex>...</sex>.<age>4</age>.<imageid>
99999</imageid><location></location>.<userauthority>2</userauthority>.
<userspeakstatus>NO</userspeakstatus>.<uservideostatus>NO</uservideost
atus>.<audioaddr>61.149.14.202</audioaddr>.<audioport>28904</audioport
>.<videoaddr>61.149.14.202</videoaddr>.<videoport>28914</videoport>.<n
attype>1</nattype>.<firewalladdr></firewalladdr>.<localvideoaddr>61.14
9.14.202</localvideoaddr>.<localvideoport>28914</localvideoport>.<loca
laudioaddr>61.149.14.202</localaudioaddr>.<localaudioport>28904</local
audioport>.<nowuserlist>.<user>hxl(a)email.com.cn</user>.<user>tuhxl@mip
hone.com.tv</user>.<user>bug(a)miphone.com.tv</user>.<user>lumy1314@dodo
doo.com</user>.<user>czl(a)dododoo.com</user>.</nowuserlist>.</commandco
ntent>.</c
I don't seem to be able to get a match when I send a call from my gw to ser
registered user. Debug indicates that user Not found in usrloc even though
the database shows the users registered. I am able to make out bound calls
the gw just fine. If anyone can shed some light in it it would be great.
Thanks
============================================================================
=================================
mysql> select * from location;
+----------+--------+------------------------+----------+-------------------
--+-------+----------------------------------+------+----------------+------
-----+-------+-------+----------------------------+
| username | domain | contact | received | expires
| q | callid | cseq | last_modified |
replicate | state | flags | user_agent |
+----------+--------+------------------------+----------+-------------------
--+-------+----------------------------------+------+----------------+------
-----+-------+-------+----------------------------+
| 9901 | | sip:9901@69.250.205.31 | NULL | 2005-02-26
03:31:09 | -1.00 | e5201b3819008718(a)192.168.199.102 | 107 | 20050226033016
| 0 | 0 | 0 | Grandstream BT100 1.0.5.11 |
+----------+--------+------------------------+----------+-------------------
--+-------+----------------------------------+------+----------------+------
-----+-------+-------+----------------------------+
1 row in set (0.01 sec)
====debugt
output======================================================================
=========================
20(18672) parse_headers: flags=256
20(18672) find_first_route: No Route headers found
20(18672) loose_route: There is no Route HF
20(18672) lookup(): '9901' Not found in usrloc
============================================================================
=================================
U 69.19.88.16:5060 -> 69.19.88.19:5060
INVITE sip:9901@69.19.88.19 SIP/2.0..Via: SIP/2.0/UDP
69.19.88.16:5060;branch=z9hG4bK2fb13d17..From: "Cell Phone MD"
<sip:4103532264
@69.19.88.16>;tag=as149fbe93..To: <sip:9901@69.19.88.19>..Contact:
<sip:4103532264@69.19.88.16>..Call-ID: 745bcf587074e77d4a8118dc212
ccba7@69.19.88.16..CSeq: 102 INVITE..User-Agent: Asterisk PBX..Date: Sat,
26 Feb 2005 08:41:01 GMT..Allow: INVITE, ACK, CANCEL, OPTIONS
, BYE, REFER..Content-Type: application/sdp..Content-Length:
240....v=0..o=root 11581 11581 IN IP4 69.19.88.16..s=session..c=IN IP4 66.
159.88.16..t=0 0..m=audio 14934 RTP/AVP 0 8 101..a=rtpmap:0
PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:1
01 0-16..a=silenceSupp:off - - - -..
#
U 69.19.88.19:5060 -> 69.19.88.16:5060
SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP
69.19.88.16:5060;branch=z9hG4bK2fb13d17..From: "Cell Phone MD" <
sip:4103532264@69.19.88.16>;tag=as149fbe93..To:
<sip:9901@69.19.88.19>..Call-ID:
745bcf587074e77d4a8118dc212ccba7@69.19.88.16..CSeq:
102 INVITE..Server: Sip EXpress router (0.9.0
(i386/linux))..Content-Length: 0..Warning: 392 69.19.88.19:5060 "Noisy
feedback tells: p
id=18682 req_src_ip=69.19.88.16 req_src_port=5060
in_uri=sip:9901@69.19.88.19 out_uri=sip:9901@69.19.88.16:5060
via_cnt==1"....
#
U 69.19.88.19:5060 -> 69.19.88.16:5060
INVITE sip:9901@69.19.88.16:5060 SIP/2.0..Max-Forwards: 10..Record-Route:
<sip:69.19.88.19;ftag=as149fbe93;lr=on>..Via: SIP/2.0/UDP 66
.159.88.19;branch=z9hG4bK96c9.80b8ddd7.0..Via: SIP/2.0/UDP
69.19.88.16:5060;branch=z9hG4bK2fb13d17..From: "Cell Phone MD" <sip:410353
2264(a)69.19.88.16>;tag=as149fbe93..To: <sip:9901@69.19.88.19>..Contact:
<sip:4103532264@69.19.88.16>..Call-ID: 745bcf587074e77d4a8118d
c212ccba7@69.19.88.16..CSeq: 102 INVITE..User-Agent: Asterisk PBX..Date:
Sat, 26 Feb 2005 08:41:01 GMT..Allow: INVITE, ACK, CANCEL, OPT
IONS, BYE, REFER..Content-Type: application/sdp..Content-Length:
240..P-hint: GATEWAY....v=0..o=root 11581 11581 IN IP4 69.19.88.16..s=
session..c=IN IP4 69.19.88.16..t=0 0..m=audio 14934 RTP/AVP 0 8
101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone
-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -..
#
U 69.19.88.16:5060 -> 69.19.88.19:5060
SIP/2.0 482 Loop Detected..Via: SIP/2.0/UDP
69.19.88.19;branch=z9hG4bK96c9.80b8ddd7.0..Via: SIP/2.0/UDP
69.19.88.16:5060;branch=z9hG4b
K2fb13d17..From: "Cell Phone MD"
<sip:4103532264@69.19.88.16>;tag=as149fbe93..To:
<sip:9901@69.19.88.19>;tag=as149fbe93..Call-ID: 74
5bcf587074e77d4a8118dc212ccba7@69.19.88.16..CSeq: 102 INVITE..User-Agent:
Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
..Contact: <sip:4103532264@69.19.88.16>..Content-Length: 0....
==ser.cfg===================================================================
========================================
#
# $Id: serconf.sh,v 1.3 2003/11/03 13:03:58 janakj Exp $
#
# autogenerated SER configuration
#
# user: uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
# system: Linux baltodb.popdial.com 2.6.10-1.760_FC3 #1 Wed Feb 2 00:14:23
EST 2005 i686 i686 i386 GNU/Linux
# date: Sat Feb 26 02:57:50 EST 2005
#
# ----------- global configuration parameters ------------------------
/*
debug=4
fork=yes
port=5060
log_stderror=no
memlog=5
*/
mhomed=yes
fifo="/tmp/ser_fifo"
alias=baltodb.popdial.com
# uncomment to override config values for test
# /*
debug=4 # debug level (cmd line: -ddd)
fork=yes
port=5060
log_stderror=yes # (cmd line: -E)
fifo="/tmp/ser_fifox"
# */
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
children=16
# if changing fifo mode to a more restrictive value, put
# decimal value in there, e.g. dec(rw|rw|rw)=dec(666)=438
#fifo_mode=438
# ------------------ module loading ----------------------------------
loadmodule "/usr/local/lib/ser/modules/tm.so"
loadmodule "/usr/local/lib/ser/modules/sl.so"
loadmodule "/usr/local/lib/ser/modules/acc.so"
loadmodule "/usr/local/lib/ser/modules/rr.so"
loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
loadmodule "/usr/local/lib/ser/modules/mysql.so"
loadmodule "/usr/local/lib/ser/modules/usrloc.so"
loadmodule "/usr/local/lib/ser/modules/registrar.so"
loadmodule "/usr/local/lib/ser/modules/auth.so"
loadmodule "/usr/local/lib/ser/modules/auth_db.so"
loadmodule "/usr/local/lib/ser/modules/textops.so"
loadmodule "/usr/local/lib/ser/modules/uri.so"
loadmodule "/usr/local/lib/ser/modules/group.so"
loadmodule "/usr/local/lib/ser/modules/msilo.so"
loadmodule "/usr/local/lib/ser/modules/enum.so"
loadmodule "/usr/local/lib/ser/modules/uri_db.so"
# ----------------- setting module-specific parameters ---------------
# all DB urls here
#modparam("usrloc|acc|auth_db|group|msilo|uri",
"db_url","mysql://ser:heslo@localhost/ser")
modparam("usrloc|acc|auth_db|group|msilo|uri_db",
"db_url","mysql://ser:heslo@localhost/ser")
# -- usrloc params --
/* 0 -- dont use mysql, 1 -- write_through, 2--write_back */
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "timer_interval", 10)
# -- auth params --
modparam("auth_db", "calculate_ha1", yes)
#modparam("auth_db", "user_column", "user_id")
modparam("auth_db", "password_column", "password")
modparam("auth", "nonce_expire", 300)
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)
# -- acc params --
# that is the flag for which we will account -- don't forget to
modparam("acc", "db_flag", 1 )
modparam("acc", "db_missed_flag", 3 )
# -- tm params --
modparam("tm", "fr_timer", 20 )
modparam("tm", "fr_inv_timer", 90 )
modparam("tm", "wt_timer", 20 )
# -- msilo params
modparam("msilo", "registrar", "sip:registrar@baltodb.popdial.com")
# -- enum params --
#
modparam("enum", "domain_suffix", "e164.arpa.")
# ------------------------- request routing logic -------------------
# main routing logic
route{
/* ********* ROUTINE CHECKS **********************************
*/
# filter too old messages
if (!mf_process_maxfwd_header("10")) {
log("LOG: Too many hops\n");
sl_send_reply("483","Alas Too Many Hops");
break;
};
#if (len_gt( max_len )) {
if ( msg:len > max_len ) {
sl_send_reply("513", "Message too large sorry");
break;
};
# Make sure that requests dont advertise addresses
# from private IP space (RFC1918) in Contact HF
# (note: does not match with folded lines)
if (search("^(Contact|m): .*(a)(192\.168\.|10\.|172\.16)")) {
# allow RR-ed requests, as these may indicate that
# a NAT-enabled proxy takes care of it; unless it is
# a REGISTER
if ((method=="REGISTER" || !
search("^Record-Route:"))
&& !(
src_ip==192.168.0.0/16 ||
src_ip==10.0.0.0/8 || src_ip==172.16.0.0/12 )) {
log("LOG: Someone trying to register
from private IP again\n");
sl_send_reply("479", "We dont accept
private IP contacts" );
break;
};
};
# anti-spam -- if somene claims to belong to our domain in From,
# challenge him (skip REGISTERs -- we will chalenge them later)
if
(search("(From|F):.*(baltodb\.popdial\.com|66\.159\.88\.19)")) {
# invites forwarded to other domains, like FWD may
cause subsequent
# request to come from there but have iptel in From
-> verify
# only INVITEs (ignore FIFO/UAC's requests, i.e.
src_ip==myself)
if (method=="INVITE" & !(src_ip==69.19.88.19)) {
if (!(proxy_authorize(
"baltodb.popdial.com" /* realm */,
"subscriber" /*
table name */ ))) {
proxy_challenge("baltodb.popdial.com" /* realm */, "0" /* no-qop */);
break;
};
# to maintain outside credibility of our
proxy, we enforce
# username in From to equal digest
username; user with
# "john.doe" id could advertise
"bill.gates" in From otherwise;
if (!check_from()) {
log("LOG: From Cheating
attempt in INVITE\n");
sl_send_reply("403", "That
is ugly -- use From=id next time (OB)");
break;
};
# we better don't consume credentials --
some requests may be
# spiraled through our server
(sfo@iptel->7141@iptel) and the
# subsequent iteration may challenge
too, for example because of
# iptel claim in From; UACs then give up
because they
# already submitted credentials for the given realm
#consume_credentials();
}; # INVITEs claiming to come from our domain
} else if (method=="INVITE" &&
!(uri=~"[@:\.](baltodb\.popdial\.com|66\.159\.88\.19)([;:].*)*"
# ... and we serve our gateway too if
present
| uri=~"@66\.159\.88\.16([;:].*)*" )) {
#the INVITE neither claims to come from our domain
nor is it targeted to it
# -> junk it
sl_send_reply("403", "No relaying");
break;
};
/* ********* RR ********************************** */
# to be safe, record route everything; UAs may use different
# transport protocols and need to have SER in path
record_route();
# if route forces us to forward to some explicit destination,
# do so; check however first that a cheater didn't preload
# a gateway destination to bypass PSTN ACLs
if (loose_route()) {
if
(uri=~"sip:[+0-9]+@66\.159\.88\.16") {
# it is gateway -- proceed to ACLs
route(3);
break;
};
# route HF determined next hop; forward there
append_hf("P-hint: rr-enforced\r\n");
t_relay();
break;
};
/* ********* check for requests targeted out of our domain...
******* */
# sign of our domain: there is '@' (username) or : (nothing) in
# front of our domain name ; ('.' is not there -- we
handle all
# xxx.iptel.org as outbound hosts);if none of these cases
matches,
# proceed with processing of outbound requests in route[2]
if
(!(uri=~"[@:](sip[\.)?(baltodb\.popdial\.com|66\.159\.88\.19)([;:].*)*" |
uri=~"@66\.159\.88\.16([;:].*)*")) {
route(2);
break;
};
/* ************ requests for our domain ********** */
/* now, the request is for sure for our domain */
# registers always MUST be authenticated to
# avoid stealing incoming calls
if (method=="REGISTER") {
# Make sure that user's dont register infinite loops
# (note: does not match with folded lines)
if (search("^(Contact|m):
.*(a)(baltodb\.popdial\.com|66\.159\.88\.19)")) {
log(1, "LOG: alert: someone trying to
set aor==contact\n");
sl_send_reply("476", "No Server Address
in Contacts Allowed" );
break;
};
if (search("^(Contact|m):
.*66\.159\.88\.16")) {
log(1, "LOG: alert: protected
contacts\n");
sl_send_reply("476", "No Server Address
in Contacts Allowed" );
break;
};
if (!www_authorize( "baltodb.popdial.com" /*
realm */,
"subscriber" /* table name */ )) {
# challenge if none or invalid
credentials
www_challenge( "baltodb.popdial.com" /*
realm */,
"0" /* no qop -- some phones can't deal with it */);
break;
};
# prohibit attempts to grab someone else's To
address
# using valid credentials;
if (!check_to()) {
log("LOG: To Cheating attempt\n");
sl_send_reply("403", "That is ugly --
use To=id in REGISTERs");
break;
};
# it is an authenticated request, update Contact
database now
if (!save("location")) {
sl_reply_error();
};
m_dump();
break;
};
# some UACs might be fooled by Contacts our UACs generate to
make MSN
# happy (web-im, e.g.) -- tell its urneachable
if (uri=~"sip:daemon@" ) {
sl_send_reply("410", "daemon is gone");
break;
};
# is this an ENUM destination (leading +?)? give it a try, if
the lookup
# doesn't change URI, just continue
if (uri=~"sip:\+[0-9]+@") {
if (!enum_query("voice")) { # if parameter empty, it
defaults to "e2u+sip"
enum_query(""); # E2U+sip
};
} else {
# aliases (take precedences over PSTN number;
provisioning interface
# is set up to assinge aliases beginning with 8)
lookup("aliases");
};
# check again, if it is still for our domain after aliases are
resolved
if
(!(uri=~"[@:](sip[\.)?(baltodb\.popdial\.com|66\.159\.88\.19)([;:].*)*" |
uri=~"@66\.159\.88\.16([;:].*)*")) {
route(5);
break;
};
# now check if it's about PSTN destinations through
our gateway;
# note that 8.... is exempted for numerical non-gw destinations
if (uri=~"sip:\+?[0-79][0-9]*@.*") {
route(3);
break;
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
# handle user which was not found ...
route(4);
break;
};
# check whether some inventive user has uploaded gateway
# contacts to UsrLoc to bypass our authorization logic
if (uri=~"sip:[+0-9]+@66\.159\.88\.16")
{
# it is gateway -- proceed to ACLs
route(3);
break;
};
/* ... and also report on missed calls ... */
setflag(3);
# we now know we may, we know where, let it go out now!
append_hf("P-hint: USRLOC\r\n");
if (!t_relay()) {
sl_reply_error();
break;
};
}
#------------------- OUTBOUND ----------------------------------------
# routing logic for outbound requests targeted out of our domain
# (keep in mind messages to our users can end up here too: for example,
# an INVITE may be UsrLoc-ed, then the other party uses outbound
# proxy with r-uri=the usr_loced addredd (typically IP))
route[2] {
append_hf("P-hint: OUTBOUND\r\n");
t_relay();
}
#------- ALIASED OUTBOUND --------------------------------------------
# routing logic for inbound requests aliased outbound; unlike
# with real outbound requests we do not force authentication
# as these calls are server by our server and we do not want
# to disqualify unathenticated request originatiors from other
# domains
route[5] {
append_hf("P-hint: ALIASED-OUTBOUND\r\n");
t_relay();
}
#----------------- PSTN ----------------------------------------------
# logic for calls to the PSTN
route[3] {
# turn accounting on
setflag(1);
/* require all who call PSTN to be members of the "int" group;
apply ACLs only to INVITEs -- we don't need to protect other
requests, as they
don't imply charges; also it could cause troubles when a call
comes in via PSTN
and goes to a party that can't authenticate (voicemail, other
domain) -- BYEs would
fail then; exempt Cisco gateway from authentication by IP
address -- it does not
support digest
*/
if (method=="INVITE" && (!src_ip==69.19.88.16)) {
if (!proxy_authorize( "baltodb.popdial.com"
/* realm */,
"subscriber" /* table name */)) {
proxy_challenge( "baltodb.popdial.com"
/* realm */, "0" /* no qop */ );
break;
};
# let's check from=id ... avoids accounting
confusion
if (method=="INVITE" & !check_from()) {
log("LOG: From Cheating attempt\n");
sl_send_reply("403", "That is ugly --
use From=id next time (gw)");
break;
};
if(!is_user_in("credentials", "int")) {
sl_send_reply("403", "NO PSTN
Privileges...");
break;
};
consume_credentials();
}; # INVITE to authorized PSTN
# if you have passed through all the checks, let your call go to
GW!
rewritehostport("69.19.88.16:5060");
# snom conditioner
if (method=="INVITE" && search("User-Agent: snom")) {
replace("100rel, ", "");
};
append_hf("P-hint: GATEWAY\r\n");
# use UDP to guarantee well-known sender port (TCP ephemeral)
t_relay_to_udp("69.19.88.16","5060");
}
/* *********** handling of unavailable user ******************* */
route[4] {
/**/
# message store
if (method=="MESSAGE") {
t_newtran();
if (m_store("0")) {
t_reply("202", "Accepted for Later
Delivery");
} else {
t_reply("503", "Service Unavailable");
};
break;
};
/**/
# non-Voip -- just send "off-line"
if (!(method=="INVITE" || method=="ACK" || method=="CANCEL")) {
sl_send_reply("404", "Not Found");
break;
};
# voicemail subscribers ...
t_newtran();
t_reply("404", "Not Found");
# we account missed incoming calls; previous statteful
processing
# guarantees that retransmissions are not accounted
if (method=="INVITE") {
acc_db_request("404 missed call", "missed_calls");
};
}
I am getting the following errors when starting ser. I am sure it is
something in my config but I can't track it down. This was a fresh
install(no previous ver of ser on this machine.) I have include below the
first section on my config. Just let me know if any one need the complete
config
Thanks
Feb 25 18:54:11 baltodb ser[32594]: Maxfwd module- initializing
Feb 25 18:54:11 baltodb ser[32594]: INFO: udp_init: SO_RCVBUF is initially
110592
Feb 25 18:54:11 baltodb ser[32594]: INFO: udp_init: SO_RCVBUF is finally
262142
Feb 25 18:54:11 baltodb ser[32594]: INFO: udp_init: SO_RCVBUF is initially
110592
Feb 25 18:54:11 baltodb ser[32594]: INFO: udp_init: SO_RCVBUF is finally
262142
Feb 25 18:54:11 baltodb ser[32604]: INFO: fifo process starting: 32604
Feb 25 18:54:11 baltodb ser[32604]: SER: open_uac_fifo: fifo server up at
/tmp/ser_fifo...
Feb 25 18:54:11 baltodb ser[32604]: WARNING: no fifo_db_url given - fifo DB
commands disabled!
Feb 25 18:54:11 baltodb ser[32711]: new_connection(): Too many connections
Feb 25 18:54:11 baltodb ser[32711]: db_init(): Could not create a connection
Feb 25 18:54:11 baltodb ser[32711]: ERROR: uridb_db_bind: unable to connect
to the database
Feb 25 18:54:11 baltodb ser[32711]: init_mod_child(): Error while
initializing module uri_db
Feb 25 18:54:11 baltodb ser[32711]: init_children failed
Feb 25 18:54:11 baltodb ser[32604]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32607]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32613]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32616]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32619]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32620]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32623]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32626]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32629]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32632]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32635]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32641]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32644]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32610]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32636]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32647]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32650]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32653]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32655]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32664]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32662]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32667]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32670]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32656]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32673]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32675]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32683]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32684]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32676]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32685]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32686]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32687]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32688]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32695]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32697]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32698]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32699]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32700]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32701]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32709]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32702]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32710]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32724]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32725]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32712]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32713]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32714]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32722]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32723]: INFO: signal 15 received
Feb 25 18:54:11 baltodb ser[32726]: INFO: signal 15 received
Feb 25 18:54:12 baltodb ser[32594]: BUG: qm_free: freeing already freed
pointer, first free: ms_msg_list.c: msg_list_free(162) - aborting
#
# $Id: serconf.sh,v 1.3 2003/11/03 13:03:58 janakj Exp $
#
# autogenerated SER configuration
#
# user: uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
# system: Linux baltodb.popvox.com 2.6.10-1.760_FC3 #1 Wed Feb 2 00:14:23
EST 2005 i686 i686 i386 GNU/Linux
# date: Thu Feb 24 15:51:05 EST 2005
#
# ----------- global configuration parameters ------------------------
debug=3
fork=yes
port=5060
log_stderror=no
memlog=5
mhomed=yes
fifo="/tmp/ser_fifo"
alias=popvox.com
# uncomment to override config values for test
/*
debug=3 # debug level (cmd line: -ddd)
fork=no
port=5068
log_stderror=yes # (cmd line: -E)
fifo="/tmp/ser_fifox"
*/
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
children=16
# if changing fifo mode to a more restrictive value, put
# decimal value in there, e.g. dec(rw|rw|rw)=dec(666)=438
#fifo_mode=438
# ------------------ module loading ----------------------------------
loadmodule "/usr/local/lib/ser/modules/tm.so"
loadmodule "/usr/local/lib/ser/modules/sl.so"
loadmodule "/usr/local/lib/ser/modules/acc.so"
loadmodule "/usr/local/lib/ser/modules/rr.so"
loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
loadmodule "/usr/local/lib/ser/modules/mysql.so"
loadmodule "/usr/local/lib/ser/modules/usrloc.so"
loadmodule "/usr/local/lib/ser/modules/registrar.so"
loadmodule "/usr/local/lib/ser/modules/auth.so"
loadmodule "/usr/local/lib/ser/modules/auth_db.so"
loadmodule "/usr/local/lib/ser/modules/textops.so"
loadmodule "/usr/local/lib/ser/modules/uri.so"
loadmodule "/usr/local/lib/ser/modules/group.so"
loadmodule "/usr/local/lib/ser/modules/msilo.so"
loadmodule "/usr/local/lib/ser/modules/enum.so"
loadmodule "/usr/local/lib/ser/modules/uri_db.so"
# ----------------- setting module-specific parameters ---------------
# all DB urls here
modparam("usrloc|acc|auth_db|group|msilo",
"db_url","mysql://ser:heslo@localhost/ser")
# -- usrloc params --
/* 0 -- dont use mysql, 1 -- write_through, 2--write_back */
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "timer_interval", 10)
# -- auth params --
modparam("auth_db", "calculate_ha1", yes)
#modparam("auth_db", "user_column", "user_id")
modparam("auth_db", "password_column", "password")
modparam("auth", "nonce_expire", 300)
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)
# -- acc params --
# that is the flag for which we will account -- don't forget to
modparam("acc", "db_flag", 1 )
modparam("acc", "db_missed_flag", 3 )
# -- tm params --
modparam("tm", "fr_timer", 20 )
modparam("tm", "fr_inv_timer", 90 )
modparam("tm", "wt_timer", 20 )
# -- msilo params
modparam("msilo", "registrar", "sip:registrar@popvox.com")
# -- enum params --
#
modparam("enum", "domain_suffix", "e164.arpa.")
# ------------------------- request routing logic -------------------
# main routing logic
Hi
This doesnt seem to be a standard SIP method, is there any reason I would
be getting this in my logs, it always seems to come from the called
party..in this case being xlite
Iqbal
I installed the ser in Redhat 9.0. I use ngrep to capture the
packet.Sometime I got the bad UDP packet send from ser. The following is an
example(210.192.101.193 is the ser installed), before MESSAGE sip there are
illeagal chars (maybe due to the udp size limit?):
U 210.192.101.193:80 -> 218.25.90.134:31500 19036@0:1480
.P{.....MESSAGE sip:lumy1314@218.25.90.134:31500 SIP/2.0..Call-ID: 0f9
ffc6b4dbc35dd8cf153975330c83e@210.192.101.20..CSeq: 1 MESSAGE..From: "
miphone" <sip:multichat@sip.miphone.cn:20000;transport=udp>;tag=160203
74..To: <sip:lumy1314@dododoo.com>..Via: SIP/2.0/UDP 210.192.101.193:8
0;branch=z9hG4bKacb8.7ed584b7.0..Via: SIP/2.0/UDP 210.192.101.20:20000
;branch=z9hG4bK42e5063b387e084e01f8119c4491d60e..Max-Forwards: 69..Con
tent-Type: text/x-miphone-multichat..Content-Length: 995..P-hint: usrl
oc applied....<?xml version="1.0" encoding="UTF-8"?>.<miphone>.<comman
d type="add user">.<from>sip:server</from>.<to>lumy1314(a)dododoo.com</t
o>.<commandcontent>.<roomid>38563504</roomid>.<sipaddr>hxl(a)email.com.c
n</sipaddr>.<name>tuhxl-1</name>.<sex>...</sex>.<age>4</age>.<imageid>
99999</imageid><location></location>.<userauthority>2</userauthority>.
<userspeakstatus>NO</userspeakstatus>.<uservideostatus>NO</uservideost
atus>.<audioaddr>61.149.14.202</audioaddr>.<audioport>28904</audioport
>.<videoaddr>61.149.14.202</videoaddr>.<videoport>28914</videoport>.<n
attype>1</nattype>.<firewalladdr></firewalladdr>.<localvideoaddr>61.14
9.14.202</localvideoaddr>.<localvideoport>28914</localvideoport>.<loca
laudioaddr>61.149.14.202</localaudioaddr>.<localaudioport>28904</local
audioport>.<nowuserlist>.<user>hxl(a)email.com.cn</user>.<user>tuhxl@mip
hone.com.tv</user>.<user>bug(a)miphone.com.tv</user>.<user>lumy1314@dodo
doo.com</user>.<user>czl(a)dododoo.com</user>.</nowuserlist>.</commandco
ntent>.</c
