I have also had problems with getting the ACK back.
I don't completely understand your configuration, you
must allow for packets going both directions, right?
Here is my config :
route
{
# check to see if the message has been around too long
# probably means that it is looping
#
if (!mf_process_maxfwd_header("10"))
{
log("LOG: Too many hops\n");
sl_send_reply("483","Too Many Hops");
break;
};
#
# make sure the length of the message isn't too long!
#
if (len_gt( max_len ))
{
sl_send_reply("513", "Wow -- Message too large");
break;
};
#
# do the loose-routing thing, this is important!
#
if(loose_route())
{
log(1,"doing top loose route");
t_relay();
break;
};
# this is where I was dropping the ACKS.
# I was simply dropping these, but they must be relayed
# because they can be ACKs
if(!(uri==myself))
{
if(!t_relay())
{
sl_reply_error();
break;
};
break;
};
This gets the ACKs through for me.
By the way, I have this configured with Cisco ATAs, version 2.16.
---greg
>
>I have the same problem and posed it to the group yesterday ([Serusers]
>Ignored 200 OK message.) So far the only workaround that I have found is to
>use the rules in my gateway to rewrite the dialed digits before sending them
>to the PSTN PRI, thus leaving the origianl URI intact for SIP
>communications.
>
>One person told me that this is a bug in the Cisco ATA, but it happens on my
>IPDialog phones also. It seems to me that the INVITE is being processed by
>the SER dial rules and is rewritten, but the ACK is not.
>
>Sean
>_______________________________________________
>
>Sean Robertson
>
>NETXUSA
>p. 800-289-6389
>f. 864-233-4344 "Ask me about Voice over IP."
>http://www.netxusa.com/
>
>----- Original Message -----
>From: "Alexander Mayrhofer" <axelm(a)nic.at>
>To: <serusers(a)lists.iptel.org>
>Sent: Friday, June 27, 2003 12:15 PM
>Subject: [Serusers] rewrite & ACK forwarding problem
>
>
>>
>> Hi,
>>
>> we're running SER together with a PSTN Gateway. Before a call get's
>> forwarded to the gateway, we are rewriting the request URI to make
>> rewriting on the GW as simple as possible:
>>
>> route {
>> ...
>> strip(3); # +43xxx -> xxx
>> prefix("0"); # xxx -> 0xxx
>> rewritehostport(xxx.xxx.xxx.xxx, 5060); # request to gateway
>> route(1);
>> break;
>> ...
>>
>> SIP call flow looks like (record route enabled):
>>
>> (1) phone -> SER
>> INVITE sip:*43699xxxxxxxx@nic.at43.at SIP/2.0
>>
>> (2) SER -> phone
>> SIP/2.0 100 trying -- your call is important to us
>>
>> (3) SER -> GW
>> INVITE sip:0699xxxxxxxx@xx.xx.xx.xx:5060 SIP/2.0
>>
>> (4) GW -> SER
>> SIP/2.0 100 Trying
>>
>> (5) GW -> SER
>> SIP/2.0 183 Session Progress
>>
>> (6) SER -> phone
>> SIP/2.0 183 Session Progress
>>
>> (7) GW -> SER
>> SIP/2.0 180 Ringing
>>
>> (8) SER -> phone
>> SIP/2.0 180 Ringing
>>
>> (9) GW -> SER
>> SIP/2.0 200 OK
>> Contact: <sip:0699xxxxxxxx@xx.xx.xx.xx:5060>
>>
>> (10) SER -> phone
>> SIP/2.0 200 OK
>> Contact: <sip:0699xxxxxxx@xx.xx.xx.xx:5060>
>>
>> [ call established, we can talk, but ... ]
>>
>> (11) phone -> SER
>> ACK sip:0699xxxxxxxx@xx.xx.xx.xx:5060 SIP/2.0
>>
>> --> Here starts the problem. That ACK (11) never gets forwarded to the
>> Gateway, so after a few seconds, the GW starts over at (9). Those three
>> packets (9-11) repeat a few times until GW runs into a timeout and drops
>> the call.
>>
>> I have the impression that SER can't match the packet to the previous
>> requests because of the rewritten URI. Is that correct?
>>
>> The only output at debug level 3 is:
>>
>> Warning: sl_send_reply: I won't send a reply for ACK!!
>>
>> Is that a routing goof somewhere in our scripts or is that a more
>> generic problem? Is the problem that the warning indicates somehow
>> related to the fact that the ACK is not being forwarded?
>>
>> Help appreciated.
>>
>> cheers
>>
>> axelm
>>
>> _______________________________________________
>> 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 List,
i tried on asterisk list as well, but any of you can give any idea abt SIP authenticatin problem with Asterisk and SIP UA (i tried SIPPS and X-Lite)
I could not properly get authenticated with my SIP UA to asterisk. i m using a username for UA "12321" and following are SIP.conf file user params
[12321]
type=friend
username=12321
host=dynamic
secret=ccarta
context=default
mailbox=1234,2345 ; Mailbox for message waiting indicator
[77777]
type=friend
username=77777
host=dynamic
secret=atracc
context=default
mailbox=1234,2345
m trying with SIPPS UA, that gets status "Acquired", not "Registered", Can anyone give any idea about it? I tried same with X-Lite, didnt work.
Sip debug messages are pasted below.
Best Regards,
JF
Sip read:
REGISTER sip:192.168.100.71 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.66:5062;branch=z9hG4bKnp992800961-40de3e5f192.168.100.66
From: <sip:12321@192.168.100.71>;tag=3b2cf0ba
To: <sip:12321@192.168.100.71>
Call-ID: 990209125-415b5d61@990209122-415b5d5e
Contact: ccarta <sip:12321@192.168.100.66:5062>;expires=600;q=0.500
Expires: 600
CSeq: 1 REGISTER
Content-Length: 0
User-Agent: Ahead SIPPS IP Phone Version 2.0.42.13
10 headers, 0 lines
Using latest request as basis request
Sending to 192.168.100.66 : 5062 (non-NAT)
Transmitting (no NAT):
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.100.66:5062;branch=z9hG4bKnp992800961-40de3e5f192.168.100.66
From: <sip:12321@192.168.100.71>;tag=3b2cf0ba
To: <sip:12321@192.168.100.71>;tag=as648287fa
Call-ID: 990209125-415b5d61@990209122-415b5d5e
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:12321@192.168.100.71>
Content-Length: 0
to 192.168.100.66:5062
Transmitting (no NAT):
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.100.66:5062;branch=z9hG4bKnp992800961-40de3e5f192.168.100.66
From: <sip:12321@192.168.100.71>;tag=3b2cf0ba
To: <sip:12321@192.168.100.71>;tag=as648287fa
Call-ID: 990209125-415b5d61@990209122-415b5d5e
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:12321@192.168.100.71>
Proxy-Authenticate: Digest realm="asterisk", nonce="7c7fba4d"
Content-Length: 0
to 192.168.100.66:5062
Sip read:
REGISTER sip:192.168.100.71 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.66:5062;branch=z9hG4bKnp992804895-411b471d192.168.100.66
From: <sip:12321@192.168.100.71>;tag=3b2d0018
To: <sip:12321@192.168.100.71>
Call-ID: 990209125-415b5d61@990209122-415b5d5e
Contact: ccarta <sip:12321@192.168.100.66:5062>;expires=600;q=0.500
Expires: 600
CSeq: 2 REGISTER
Content-Length: 0
Proxy-Authorization: Digest username="12321",realm="asterisk",uri="sip:192.168.100.66",nonce="7c7fba4d",nc="00000001",response="b8b1d7fc53eff354dfc31dfa3f800749"
User-Agent: Ahead SIPPS IP Phone Version 2.0.42.13
11 headers, 0 lines
Using latest request as basis request
Sending to 192.168.100.66 : 5062 (non-NAT)
Transmitting (no NAT):
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.100.66:5062;branch=z9hG4bKnp992804895-411b471d192.168.100.66
From: <sip:12321@192.168.100.71>;tag=3b2d0018
To: <sip:12321@192.168.100.71>;tag=as648287fa
Call-ID: 990209125-415b5d61@990209122-415b5d5e
CSeq: 2 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:12321@192.168.100.71>
Content-Length: 0
to 192.168.100.66:5062
Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.100.66:5062;branch=z9hG4bKnp992804895-411b471d192.168.100.66
From: <sip:12321@192.168.100.71>;tag=3b2d0018
To: <sip:12321@192.168.100.71>;tag=as648287fa
Call-ID: 990209125-415b5d61@990209122-415b5d5e
CSeq: 2 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Expires: 600
Contact: <sip:12321@192.168.100.71>;expires=600
Date: Tue, 14 Oct 2003 13:46:14 GMT
Content-Length: 0
to 192.168.100.66:5062
11 headers, 2 lines
Reliably Transmitting:
NOTIFY sip:12321@192.168.100.66:5062 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.71:5060;branch=z9hG4bK3ecb7a3b
From: "asterisk" <sip:asterisk@192.168.100.71>;tag=as3f6e8c0e
To: <sip:12321@192.168.100.66:5062>
Contact: <sip:asterisk@192.168.100.71>
Call-ID: 074dfadf24b95dd75e17b56c67ffcaf1(a)192.168.100.71
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 36
Messages-Waiting: no
Voicemail: 0/0
(no NAT) to 192.168.100.66:5062
Sip read:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.100.71;branch=z9hG4bK3ecb7a3b
From: "asterisk" <sip:asterisk@192.168.100.71>;tag=as3f6e8c0e
To: <sip:12321@192.168.100.66:5062>;tag=3b302259
Call-ID: 074dfadf24b95dd75e17b56c67ffcaf1(a)192.168.100.71
CSeq: 102 NOTIFY
User-Agent: Ahead SIPPS IP Phone Version 2.0.42.13
Content-Length: 0
8 headers, 0 lines
---------------------------------
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
At 07:39 PM 8/14/2003, Chad Brown wrote:
>Perfect,
>
>Let me ask 2 quick follow-on questions...
>
>1. Can I go back to http://www.iptel.org/ser/tarball/ser_8_11_stable.tgz
>to get the latest patched and STABLE builds?
That's the latest, most stable source, you need to compile it myself.
There will be a new complete distribution by end of this month -- we are now
waiting to run SER through the upcoming SIPIT to release it.
>2. What location / version of the modules should I use when running
>builds for this location? (Serweb, mysql, jabber, etc)
All SER modules are included there.
uptodate SERWEB is now in the http://www.iptel.org/ser/tarball/ directory too.
-jiri
I'd like to run multiple SER instances on the same
database. I knew from previous experiments that
would not be possible because of the cache.
However, I just tried running multiple SER instances,
on the same database, but in different domains. This did
not work, they both wrote over each others location
entries in the database even though the domains on
each SER instance were different.
SER knows which domain it is in because of the
www_authorize("named.com", "subscriber")
authentication challenge.
So it seems reasonable that this instance of SER should only
mess with authorizations that it challenged. Perhaps the
problem is with the initial load of 'previous' registrations.
When SER starts, it loads the current location table. During
the load, ALL domains are loaded. Perhaps only the domains
listed by the 'alias="domain"' should be loaded and tracked,
and all of the rest should be ignored for each instance of SER?
---greg
Hi,
I have radius authentication working thanks to Jan's help but I am still not receiving any accounting messages to my radius server. I found a mention of setting radius_log_flag but ser 0.9.11 tells me it isn't found in the "acc" module. How can I set invite and goodbye messages (or any others for that matter) to send information to my radius server for accounting purposes. I
have read at leat 90% of the old messages but have yet to find an answer.
Thanks in advance,
Steve
Hi!
sems version 1.0 is for ser0.8.11
the cvs version of sems is for ser0.8.12
klaus
> -----Original Message-----
> From: Mario Kolberg [mailto:mko@cs.stir.ac.uk]
> Sent: Friday, November 28, 2003 5:50 PM
> To: serusers
> Subject: [Serusers] Re: voicemail config
>
>
> Hi,
>
> thanks for your help! I have now the two instances of ser working ok.
> The vm ser instance also writes the message to the fifo and this is
> picked up by Sems. However, Sems is complaining about the "wrong FIFO
> interface version". Sems seems to pick up version 0.2. This
> matches what
> the ser proxy writes to the FIFO. I run ser 0.8.12 (stable
> version) and
> sems version 0.1.0 which appears to be the most recent.
>
> How can I make ser and sems agree on the FIFO interface version?
>
> Thanks,
> Mario
>
>
>
> --
> The University of Stirling is a university established in Scotland by
> charter at Stirling, FK9 4LA. Privileged/Confidential Information may
> be contained in this message. If you are not the addressee indicated
> in this message (or responsible for delivery of the message to such
> person), you may not disclose, copy or deliver this message to anyone
> and any action taken or omitted to be taken in reliance on it, is
> prohibited and may be unlawful. In such case, you should destroy this
> message and kindly notify the sender by reply email. Please advise
> immediately if you or your employer do not consent to Internet email
> for messages of this kind.
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
FYI,
The Grandstream phones work great with SER provided the numeric aliases
can be used to reach endpoints. The Grandstream can only dial numeric
numbers and not generic sip URI/URLs. It would be great if there was a
lookup available underneath the http://www.iptel.org/user/index.php
(MyAccount link)->(phone book tab)->(find user link) to find numeric
aliases to reach iptel.org users, provided you got the correct non
numeric SIP URIs of iptel.org users.
Also, the peering prefix for an iptel.org user to reach and
fwd.pulver.com user apears to be in error at
http://www.fwd.pulver.com/index.php?section_id=78&PHPSESSID=06a451f4079f56c…,
a prefix of 21111 works great and **393 does not work.
Bye,
Scott Holben
sip iptel.org URIs: skaht AT iptel.org or 90931 AT iptel.org
Just found an IETF draft on how to implement PBX features in SIP
http://www.voip-info.org/tiki-index.php?page=SIP+PBX+functions
Maybe we can try to implement these in SER and document these functions
on the Wiki?
There's some of these in the source examples and in the howto's, but it
might be good to document functions one by one.
# Call Hold
# Music on Hold
# Unattended Transfer
# Consultation Hold
# Unconditional Call Forwarding
# Attended Transfer
# No Answer Call Forwarding
# Busy Call Forwarding
# Single-Line Extension
# 3-way Call
# Incoming Call Screening
# Find-Me
# Call Pickup
# Call Park
# Outgoing Call Screening
# Automatic Redial
Anyway, it's good reading material!
/Olle
I have a problem CANCELING requests when using t_on_failure. Example:
I forward the call to the PSTN gateway. Then I CANCEL the request. I am
using a second PSTN gateway for backup and I call the function
t_on_failure before t_relay:
t_on_failure("2");
if (!t_relay()) {
sl_reply_error();
};
As a result of the CANCEL request, a 487 code is received and
t_on_failure redirects the requests to the second PSTN gateway. This is
not what I expect after sending a CANCEL. The manual says all responses
> 300 are considered failures but an intended CANCEL is not a failure,
is it?
Do I miss something in the configuration to stop this from happening?
Regards,
Adrian Georgescu
ag(a)ag-projects.com
http://ag-projects.com
Tel: +31-23-5458104
IP phone: sip:ag@ag-projects.com
------------------------------------------------
DNS, ENUM & IP telephony http://managed-dns.org/
Thanks Raphael, for your reply!
I have started both SEMS & SER in debug mode and placed a test call and let it timeout and be redirected to voicemail. I've captured all output and included them in the attached files.
I've also verified that we are running the latest CVS answer_machine SEMS server, as well as SER v0.8.12.
> - be aware that in the new ser version, sql:// adresses changed to mysql:// if you are using mysql.
This is good to know! I was using "sql://", and have since changed to "mysql://". I am still getting the same problem however.. :(
I always receive the error "404 voicemail: no email address for user <8646783188>" when calling the number. This error is always returned from SEMS.
Anyone know of any reason why I might be getting this error? See attached files for debug info.
Thanks for your help!!
Regards,
Darren Nay - dnay(a)libertyisp.com
----- Original Message -----
From: Raphael Coeffic
To: Darren Nay
Cc: sems(a)lists.iptel.org
Sent: Friday, November 28, 2003 5:29 AM
Subject: Re: [Sems] SEMS - No email address error
Hello Daren,
first of all, i will need to know a few things so that i can help you.
1. enable debug log from ser:
- uncomment and change the 'fork' line to 'fork=no'
- uncomment and change the 'log_stderr' line to 'log_stderr=yes'
2. enable debug log Sems:
- start sems with '-D 3 -E' command line parameters.
3. capture the log and send them to the sems(a)lists.iptel.org list.
4. before you do anything, try updating to ser version '0_8_12' and sems' last version.
- use "cvs -d:pserver:anonymous@cvs.berlios.de:/cvsroot/ser co -r 'rel_0_8_12' sip_router"
- you can also download a tarball from the Web CVS page at developer.berlios.de, select 'rel_0_8_12' branch before.
- use "cvs -d:pserver:anonymous@cvs.berlios.de:/cvsroot/sems co answer_machine".
- you can also use the Web CVS page at developer.berlios.de.
- be aware that in the new ser version, sql:// adresses changed to mysql:// if you are using mysql.
-Raphael.
----- Original Message -----
From: Darren Nay
To: sems(a)lists.iptel.org
Sent: Thursday, November 27, 2003 1:30 AM
Subject: [Sems] SEMS - No email address error
Hello,
I posted a similar email to this one to the serusers mailing list, and so if you are subscribed to that mailing list then I appologize for sending this twice. However, I haven't had a response from the mailing list yet and saw this email address and thought that I would try it as well.
The main problem that we are having with our SER/SEMS configuration right now is that we are getting this error returned from SEMS when the call is redirected to voicemail.
Nov 26 17:40:58 jupiter Sems[2413]: Error: 404 voicemail: no email address for user <8641234567>
I'm pretty sure that SEMS is returning these error when it's called from SER as:
vm("/tmp/am_fifo","voicemail")
I've checked the user record in the "subscriber" table for this user in the "ser" database and the email address is there. I thought, at first, that this might be caused by ser being unable to connect to the mysql database (it's on a seperate server) .. I've verified that it is connecting now though.
Do you have any ideas why we might be getting this error? I have attached our ser.cfg file for the voicemail ser router below (in case it helps).
I really appreciate your time! If it helps.. Once we get all of this working then we will most likely be purchasing commercial support for these products (if you provide it). We need to get it all working first though in order to convince the boss(s) that this product will work for us (they are wary of using freeware).
Thanks for the help! I am very impressed with SER so far.
Regards,
Darren Nay - dnay(a)libertyisp.com
---
#
# $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=3 # debug level (cmd line: -dddddddddd)
#fork=yes
#log_stderror=no # (cmd line: -E)
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
fifo="/tmp/vm_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/maxfwd.so"
loadmodule "/usr/lib/ser/modules/vm.so"
# ----------------- setting module-specific parameters ---------------
modparam("voicemail", "db_url","sql://servm:servm55@10.10.0.55/ser")
modparam("voicemail", "subscriber_table", "subscriber")
modparam("voicemail", "email_column", "email_address")
# ------------------------- request routing logic -------------------
# main routing logic
alias="10.10.0.58"
alias="jupiter.ion.dom"
route{
# initial sanity checks -- messages with
# max_forwars==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if (!uri==myself) {
sl_send_reply("404", "not reponsible for host in r-uri");
break;
};
# Voicemail specific configuration - begin
if(method=="ACK" || method=="INVITE" || method=="BYE"){
if (!t_newtran()) {
log("could not create new transaction\n");
sl_send_reply("500","could not create new transaction");
break;
};
t_reply("100","Trying -- just wait a minute !");
if(method=="INVITE"){
log("**************** vm start - begin ******************\n");
if (uri=~"sip:as_welcome@.*" || uri=~"sip:as_nomoney@.*") {
if (!vm("/tmp/am_fifo", "announcement")) {
log("couldn't contact announcement server\n");
t_reply("500", "couldn not contact announcement server");
};
} else {
if(!vm("/tmp/am_fifo","voicemail")){
log("could not contact the answer machine\n");
t_reply("500","could not contact the answer machine");
};
};
log("**************** vm start - end ******************\n");
} else if(method=="BYE"){
log("**************** vm end - begin ******************\n");
if(!vm("/tmp/am_fifo","bye")){
log("could not contact the answer machine\n");
t_reply("500","could not contact the answer machine");
};
log("**************** vm end - end ******************\n");
};
break;
};
if (method=="CANCEL") {
sl_send_reply("200", "cancels are junked here");
break;
};
sl_send_reply("501", "method not understood here");
}
----------------------------------------------------------------------------
_______________________________________________
Sems mailing list
sems(a)lists.iptel.org
http://lists.iptel.org/cgi-bin/mailman/listinfo/sems
