November 2003 - sr-users

Re: [Serusers] rewrite & ACK forwarding problem
by lgfausak＠august.net 30 Apr '04

30 Apr '04

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 >

4 5

[Serusers] If anyone can comment of asterisk problem
by John Foster 30 Jan '04

30 Jan '04

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

2 2

RE: [Serusers] Latest STABLE build without using CVS
by Jiri Kuthan 20 Jan '04

20 Jan '04

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

3 2

[Serusers] multiple SER instances / REGISTRATION problem
by Greg Fausak 17 Jan '04

17 Jan '04

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

7 18

[Serusers] Radius accounting - radius_log_flag?
by Steven R. Bunin 16 Jan '04

16 Jan '04

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

3 4

RE: [Serusers] Re: voicemail config
by Klaus Darilion 04 Dec '03

04 Dec '03

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 > >

8 18

[Serusers] Grandstream
by Scott Holben 02 Dec '03

02 Dec '03

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

3 3

[Serusers] IP Centrex features
by Olle E. Johansson 02 Dec '03

02 Dec '03

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

3 2

[Serusers] t_on_failure also when CANCEL?
by Adrian Georgescu 01 Dec '03

01 Dec '03

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/

2 1

Re: [Serusers] SEMS - No email address error
by Darren Nay 30 Nov '03

30 Nov '03

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

2 2