Hi Jiri!
We have a similar problem that you described with UDP bind through a
Cisco PIX501 firewall. We are using port 5080 and the replies Resource
temporarily unavailable.
Did you ever get an answer to your problem? I really appreciate if you
can answer me soon!
regards
Anders
Anders Wikström
Si ATM AB
Hamngatan 27
172 66 Sundbyberg
+46 (0)8 982300
Mobile +46 (0)70 5682281
Hi,
I am making some progress. I still can not call "internal" sip-sip
numbers, but now, instead of insisting on forwarding to the gateway, SER
404's. Debug says that the called party is not in usrloc, although I can
see the entry in the location table in the db.
I have attached my ser.cfg, output from debug, and ngrep in the hope
that someone can show me the error of my ways.
-------------ser.cfg------------------------------------------
#
# $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 andrei Exp $
#
# simple quick-start config script
#
# ----------- global configuration parameters ------------------------
debug=4 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=no # (cmd line: -E)
/* Uncomment these lines to enter debugging mode
#debug=7
#fork=no
#log_stderror=yes
*/
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=yes # (cmd. line: -R)
#port=5060
children=4
fifo="/tmp/ser_fifo"
# ------------------ module loading ----------------------------------
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/domain.so"
loadmodule "/usr/lib/ser/modules/auth.so"
loadmodule "/usr/lib/ser/modules/auth_db.so"
loadmodule "/usr/lib/ser/modules/acc.so"
loadmodule "/usr/lib/ser/modules/exec.so"
loadmodule "/usr/lib/ser/modules/group.so"
#loadmodule "/usr/lib/ser/modules/msilo.so"
#loadmodule "/usr/lib/ser/modules/print.so"
#loadmodule "/usr/lib/ser/modules/textops.so"
#loadmodule "/usr/lib/ser/modules/jabber.so"
loadmodule "/usr/lib/ser/modules/uri.so"
#loadmodule "/usr/lib/ser/modules/vm.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
#modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line
modparam("usrloc", "db_mode", 2)
# -- auth params --
# Uncomment if you are using auth module
#
#modparam("usrloc", "db_url", "sql://ser:<password>@localhost/ser")
modparam("usrloc", "db_url", "sql://ser:heslo@wlgcd1:3306/ser")
modparam("auth_db", "db_url", "sql://ser:heslo@wlgcd1:3306/ser")
modparam("group", "db_url", "sql://ser:heslo@wlgcd1:3306/ser")
modparam("uri", "db_url", "sql://ser:heslo@wlgcd1:3306/ser")
modparam("domain", "db_url", "sql://ser:heslo@wlgcd1:3306/ser")
modparam("auth_db", "calculate_ha1", yes)
#
# If you set "calculate_ha1" parameter to yes (which true in this
config),
# uncomment also the following parameter)
#
modparam("auth_db", "password_column", "password")
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)
# -- acc params --
modparam("acc", "log_level", 1)
# that is the flag for which we will account -- don't forget to
# set the same one :-)
modparam("acc", "log_flag", 2 )
# ------------------------- Domains Covered ------------------------
alias="fx.net.nz"
alias="vixen"
alias="vixen.fx.net.nz"
alias="202.53.189.50"
alias="special.fx.net.nz"
alias="wlgvx1.fx.net.nz"
#alias="202.53.189.23"
#alias="202.49.159.10"
# ------------------------- 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","Too Many Hops");
break;
};
if (msg:len > max_len) {
sl_send_reply("513", "Wow -- Message too large");
break;
};
/* ********* RR ********************************** */
/* grant Route routing if route headers present */
if (loose_route()) { t_relay(); break; };
setflag(2);
/* record-route INVITEs -- all subsequent requests must visit us
*/
if (method=="INVITE") {
record_route();
};
lookup("aliases");
if (uri==myself) {
if (method=="REGISTER") {
# digest authentication
log(1,"request for registration");
if (!www_authorize("vixen.fx.net.nz",
"subscriber"))
{
www_challenge("vixen.fx.net.nz", "0");
break;
};
# setflag(3);
save("location");
break;
};
}
# now check if it really is a PSTN destination which should be
handled
# by our gateway; if not, and the request is an invitation, drop
it --
# we cannot terminate it in PSTN; relay non-INVITE requests --
it may
# be for example BYEs sent by gateway to call originator
if (!uri=~"sip:\+?[0-9]+@.*")
{if (method=="INVITE") {
sl_send_reply("403", "Call cannot be served
here");
} else
{
forward(uri:host, uri:port);
};
break;
};
# account completed transactions via syslog
setflag(1);
# free call destinations ... no authentication needed
if ( is_user_in("Request-URI", "local") /* free destinations */
| uri=~"sip:[8][0-9][0-9][0-9]@.*" /* local
PBX */
| uri=~"sip:98[0-9][0-9][0-9][0-9]") {
log("free call");
} else if (src_ip==202.7.4.40) {
# our gateway doesn't support digest authentication;
# verify that a request is coming from it by source
# address
log("gateway-originated request");
} else {
# in all other cases, we need to check the request
against
# access control lists; first of all, verify request
# originator's identity
if (!proxy_authorize( "vixen.fx.net.nz" /* realm */,
"subscriber" /* table name */)) {
proxy_challenge( "vixen.fx.net.nz" /* realm */,
"0" /* no qop */ );
break;
};
# authorize only for INVITEs -- RR/Contact may result in
weird
# things showing up in d-uri that would break our logic;
our
# major concern is INVITE which causes PSTN costs
if (method=="INVITE") {
# does the authenticated user have a permission
for local
# calls (destinations beginning with a single
zero)?
# (i.e., is he in the "local" group?)
if (uri=~"sip:0[1-9][0-9]+@.*") {
if (!is_user_in("credentials", "local"))
{
sl_send_reply("403", "No
permission for local calls");
break;
};
# the same for long-distance (destinations begin
with two zeros")
} else if (uri=~"sip:00[1-9][0-9]+@.*") {
if (!is_user_in("credentials", "ld")) {
sl_send_reply("403", " no
permission for LD ");
break;
};
# the same for international calls (three zeros)
} else if (uri=~"sip:000[1-9][0-9]+@.*") {
if (!is_user_in("credentials", "int")) {
sl_send_reply("403",
"International permissions needed");
break;
};
# everything else (e.g., interplanetary calls)
is denied
} else {
sl_send_reply("403", "Forbidden");
break;
};
}; # INVITE to authorized PSTN
};
# if you have passed through all the checks, let your call go to
the next stage!
# native SIP destinations are handled using our USRLOC DB
if(!lookup("aliases")){
log(1,"Couldn't find any
matching alias");
sl_send_reply("404", "User does
not exist");
break;
};
if(!lookup("location")) {
log(1,"unable to locate user");
# attempt handoff to PSTN.
log( "Forwarding to PSTN\n" );
rewritehost( "202.7.4.40" );
forward( "202.7.4.40", 5060 );
----------end ser.cfg----------------------------------------
-------------------debug-------------------------------------
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: SIP Request:
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: method: <INVITE>
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: uri:
<sip:8923@202.53.189.50;user=phone>
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: version: <SIP/2.0>
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: parse_headers: flags=1
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: end of header reached,
state=5
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: parse_headers: Via found,
flags=1
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: parse_headers: this is the
first via
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: After parse_msg...
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: preparing to run routing
scripts...
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: DEBUG : is_maxfwd_present:
searching for max_forwards header
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: parse_headers: flags=128
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: end of header reached,
state=9
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: DEBUG: get_hdr_field: <To>
[37]; uri=[sip:8923@202.53.189.50;user=phone]
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: DEBUG: to body
[<sip:8923@202.53.189.50;user=phone>^M ]
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: get_hdr_field: cseq <CSeq>:
<1> <INVITE>
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: DEBUG: get_hdr_body :
content_length=250
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: found end of header
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: DEBUG: is_maxfwd_present:
max_forwards header not found!
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: parse_headers: flags=256
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: find_first_route(): No Route
headers found
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: loose_route(): There is no
Route HF
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: DEBUG: add_param:
tag=4082266747
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: end of header reached,
state=29
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: lookup(): '8923' Not found in
usrloc
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: check_self - checking if
host==us: 13==9 && [202.53.189.50] == [127.0.0.1]
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: check_self - checking if port
5060 matches port 5060
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: check_self - checking if
host==us: 13==13 && [202.53.189.50] == [202.53.189.50]
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: check_self - checking if port
5060 matches port 5060
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: query="select grp from grp
where username='8923' AND grp='local'"
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: is_user_in(): User is in
group 'local'
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: free call
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: lookup(): '8923' Not found in
usrloc
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: Couldn't find any matching
alias
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: parse_headers: flags=-1
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]:
check_via_address(202.53.189.24, 202.53.189.24, 2)
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: DEBUG:destroy_avp_list:
destroing list (nil)
Sep 16 11:14:16 vixen /usr/sbin/ser[4228]: receive_msg: cleaning up
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: SIP Request:
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: method: <ACK>
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: uri:
<sip:8923@202.53.189.50;user=phone>
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: version: <SIP/2.0>
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: parse_headers: flags=1
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: end of header reached,
state=5
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: parse_headers: Via found,
flags=1
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: parse_headers: this is the
first via
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: After parse_msg...
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: preparing to run routing
scripts...
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: parse_headers: flags=4
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: DEBUG: add_param:
tag=b27e1a1d33761e85846fc98f5f3a7e58.bfe0
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: end of header reached,
state=29
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: DEBUG: get_hdr_field: <To>
[79]; uri=[sip:8923@202.53.189.50;user=phone]
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: DEBUG: to body
[<sip:8923@202.53.189.50;user=phone>]
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: DEBUG: sl_filter_ACK : local
ACK found -> dropping it!
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: DEBUG:destroy_avp_list:
destroing list (nil)
Sep 16 11:14:16 vixen /usr/sbin/ser[4230]: receive_msg: cleaning up
------------------------end debug---------------------------------
-------------------------ngrep port 5060--------------------------
#
U 202.53.189.24:5060 -> 202.53.189.50:5060
INVITE sip:8923@202.53.189.50;user=phone SIP/2.0..Via: SIP/2.0/UDP
202.53.189.24:5060..From: <sip:4748880@202.53.189.50;user=phone>;t
ag=3978441923..To: <sip:8923@202.53.189.50;user=phone>..Call-ID:
2139243568@202.53.189.24..CSeq: 1 INVITE..Contact: <sip:4748880@202
.53.189.24:5060;user=phone;transport=udp>..User-Agent: Cisco ATA
v2.15 ata18x (020927a)..Expires: 300..Content-Length: 252..Content-T
ype: application/sdp....v=0..o=4748880 12924 12924 IN IP4
202.53.189.24..s=ATA186 Call..c=IN IP4 202.53.189.24..t=0 0..m=audio
16384 R
TP/AVP 0 4 8 101..a=rtpmap:0 PCMU/8000/1..a=rtpmap:4
G723/8000/1..a=rtpmap:8 PCMA/8000/1..a=rtpmap:101
telephone-event/8000..a=fmtp:10
1 0-15..
#
U 202.53.189.50:5060 -> 202.53.189.24:5060
SIP/2.0 404 User does not exist..Via: SIP/2.0/UDP
202.53.189.24:5060..From:
<sip:4748880@202.53.189.50;user=phone>;tag=3978441923..To
:
<sip:8923@202.53.189.50;user=phone>;tag=b27e1a1d33761e85846fc98f5f3a7e58.bfe0..Call-ID: 2139243568@202.53.189.24..CSeq: 1 INVITE..S
erver: Sip EXpress router (0.8.14 (i386/linux))..Content-Length:
0..Warning: 392 202.53.189.50:5060 "Noisy feedback tells: pid=4231 r
eq_src_ip=202.53.189.24 req_src_port=5060
in_uri=sip:8923@202.53.189.50;user=phone
out_uri=sip:8923@202.53.189.50;user=phone via_cnt==
1"....
#
U 202.53.189.24:5060 -> 202.53.189.50:5060
ACK sip:8923@202.53.189.50;user=phone SIP/2.0..Via: SIP/2.0/UDP
202.53.189.24:5060..From: <sip:4748880@202.53.189.50;user=phone>;tag=
3978441923..To:
<sip:8923@202.53.189.50;user=phone>;tag=b27e1a1d33761e85846fc98f5f3a7e58.bfe0..Call-ID: 2139243568@202.53.189.24..CSe
q: 1 ACK..User-Agent: Cisco ATA v2.15 ata18x
(020927a)..Content-Length: 0....
exit
--------------------end-----------------------------------------
--
My questions involve using SER/Asterisk in a carrier style setup and not
an office PBX.
I have SER working with Asterisk. Asterisk has the ability to do
standard call features as described at
http://www.voip-info.org/wiki-PBX+features My question is how does someone
with a SER/Asterisk setup get SER to use those features? Explanation below.
For example, say a SIP caller forwards his calls to a PSTN number like a
cell phone. If this person is called by another SIP phone, the Asterisk
server is never contacted, correct? How does SER know to forward the call?
Does that make sense?
Some of the documentation I've read says that many features are handled
by the SIP phone itself. I can understand that when it comes to caller-id
but what about call forwarding. Surely I'm not expected to have my internet
connection and SIP phone online just to ensure my calls are forwarded.
Are most carrier installations setup using MGCP? I understand that's how
AT&T is setup and that's why they can't be used from behind a NAT.
Bill
Have you enabled symmetric nat in the Cisco phone? This is under the
setting "NAT == YES"?
Dave
-----Original Message-----
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Morten Kuehl
Sent: 14 September 2004 10:50
To: serusers(a)lists.iptel.org
Subject: RE: [Serusers] NAT with SER and ASTERISK, strange behaviour
Hi,
I am aware of the difference between media and signalling as well as the
way an rtp proxy works. But still do I think that this is a different
case:
When using asterisk, xlite does symetric rtp streams aka. sends from
port
8000 and listens on port 8000. The port is therefore open on nat and udp
pakets can travel through the nat with the correct public ip in the sip
messages.
When I do have the setup with ser and the sip messages look the same,
aka.
xlite says "I am listening on 8000 on public ip" and send via 8000 to
the
cisco phone which says "I am listening on port x on my ip". So there
should be no need for an rtp proxy as the rtp stream from xlite is
symetric and the nat port is open. But still there is no incoming audio.
I
can understand that with clients like MS messenger there is a need to
rewrite the sdp and sip messages.
So where is the problem in my szenario, what little magic does asterisk
do
that I do not see in the sip messages???
Cheers
Morten
> SER is simply a proxy - it does not handle media in the same way that
> asterisk does. When you have both clients registered with SER, once
the
> initial call set up has been completed, no further traffic runs
through
> SER. Search this list for explanations as to why RTP traffic doesn't
> really run through NAT without a helping hand.
>
> If you want to be able to make calls without any special client/NAT
> router settings, check out RTPproxy/NAThelper and Mediaproxy - they do
> the RTP proxy bit that Asterisk has built in.
>
> Hope this helps.
>
> Dave
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
The question is just about that in the subject ...
Do I need, as Dan Austin's howto says, a DNS SVR Resrouce Record, or can
I just use IP numbers, instead of names ? The thing is I have some
doubts:
- the variable SIP_DOMAIN needs to be a name or can it be just an IP
number ?
- if so, I believe that at the ser.cfg file, I can put uri="a.b.c.d"
instead of uri="mydomain.com"
- if so, I can write down if (!www_authorize("a.b.c.d", .... ) instead
of if (!www_authorize("mydomain.com", .... )
- how is related the sip domain to the host name and domain, set both
respectively by hostname and domainname commands in linux ?? In other
words, does the domain name of my host needs to be the sip domain ?
- what is a realm ?
Thanx a lot
Lucas
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
I see that ser can be used to make calls to pstn gateways ( normal
phone numbers). Can Ser be used to recieve calls from normal phones
and Ser users have real telephone numbers assigned to there account.
Thanks
Hi list,
I'm sorry to ask this to the list, as I'm sure I've seen the information
before but after some googling I can't really find it. Can anyone shed
some light on the status of the presence module at the moment? How far
developed is it? Which methods does it now support? Can people
subscribe with their regular ser username? I know there's been some
work on it recently, and any info would be gratefully received.
Many thanks :-)
Dave
-------------------------------------
Dave Bath
dave(a)fuuz.com
www.fuuz.com
07736 232085
NOTE: The information contained in this email is intended for the named
recipients only, it may be privileged and confidential. If you are not
the intended recipient, you must not copy distribute or take any action
in reliance upon it. No warranties or assurances are made in relation to
the safety and content of this email and any attachments. No liability
is accepted for any consequences arising from it
Hi..I have a ser with media proxy installed..I want to verify if the media
packets pass through my server and they don\t go directly between the two
phones between which the phone session takes place.How can I verify if the
media packets go through my server? How should the uri look like in this
case ?..I mention that I have access on the voice gateway (cisco )
Thanks for the help with this question. The manual provides an example
for a creating a header when diverting to voicemail for a negative
response. To support the draft
http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-08.txt a
reason (e.g. 486 busy here) would need to be understood in order to
support the diversion header. From the example and the ser
documentation, it appears as if there is no current method to detect
exactly which 4xx response was returned. Is my statement correct?
(Clipped from ser user's documentation)
Example 3-11. Forwarding to PBX/Voicemail via Cisco Gateways
route{
# if we do not get a positive reply, continue at reply_route[2]
t_on_failure("2");
# forward the request to all destinations in destination set now
t_relay();
}
failure_route[2] {
# request failed (no reply, busy, whatever) ... forward it again
# to pbx's voicemail at phone number 6000 via Cisco gateway at
# 192.168.10.10; append proprietary CC-Diversion header field
with
# original request uri in it, so that the gateway and voicemail
# know, whom the request was originally intended for
append_branch("sip:6000@192.168.10.10");
append_urihf("CC-Diversion: ", "\r\n");
t_relay();
}
Regards,
Chris
> -----Original Message-----
>
> > Diversion header support
>
> This example from administration guide may solve some of the problems
> you are solving or at least you can use it as a programming pattern:
> http://www.iptel.org/ser/doc/seruser/seruser.html#AEN1018
>
Hi all,
I am using the following configuration to test SJPhone through IPTEL proxy
server(publicly
available:195.37.77.99).
HOST1(win2K)---FW1---Internet---FW2---HOST2(winXP)
Host1 and Host2 are hosts with private IPs having SJPhone application. FW1
and FW2 are
firewall/NAT devices with SIP-ALG implementation. This means all the SIP
messages are modified to include the public IPs in them. Also the
via,contact ports are modified. Now both host1 and host2
register with the iptel proxy server. A call is initiated from host1. Host2
sends 200 OK response
to the HOST1. After this the ACK sent by Host1 is sent to port 5060 on
HOst2,instead of the
contact port advertised in 200 OK. This is observed from ethereal captures
on Host2. All these
messages are going through the proxy server(195.37.77.99).
Can someone please tell me why the proxy server is behaving this way, i.e.
sending ACK on 5060
instead of the contact. Is there anything that i am missing here or doing
wrong.
Thanks
Mahesh
