- sr-users - kamailio.org

[Serusers] how to record conversation using rtpproxy
by nhadie 14 Sep '07

14 Sep '07

Hi, All how can i run rtpproxy to save recorded conversation locally? i tried: /usr/local/bin/rtpproxy -l 1.2.3.4 -s udp:1.2.3.4:17000 -r /var/media but got nothing under /var/media after making calls /usr/local/bin/rtpproxy -l 1.2.3.4 -s udp:1.2.3.4:17000 -r /var/media -S /var/media also got nothing? has anyone tried it? thank you regards, nhadie

1 0

[OpenSER-Users] domain name in route header
by jh＠tutpro.com 14 Sep '07

14 Sep '07

klaus, if you want to support domains in route headers, then you need to do naptr and srv lookups for the domain when handling loose routing. it is not enough to compare the domain to the ones domain module knows about. domain in route header may namely be anything as long as it resolves to your proxy. for this reason, i don't like the idea of domains in route headers. it hurts performance far too much. -- juha

1 0

[OpenSER-Users] help with outbound proxy
by Dawid Jarosławski 14 Sep '07

14 Sep '07

Hello, I'm trying to make outbound proxy for my network using OpenSER. Currently I've configured OpenSER as sip registrar/rtpproxy and it works fine even with NAT traversal. The problem is that I don't how shuould I reconfigure my config to make it work as outbound proxy. I've tried many changes with no results. The first problem is how to correctly handle the register method. My config is based on: http://siprouter.onsip.org/doc/gettingstarted/ch08s02.html Can anyone help me? Best regards, Dawid Jaroslawski

2 5

[OpenSER-Users] Patch for openserunix.c
by Patrick Miccio 14 Sep '07

14 Sep '07

Hi everyone, I use 1.1.1 notls, in my testing environment I came across some strange errors when using a home made script in combination with the openserunix util. First of all there were thousands of files like"/tmp/OpenSER.XXXXXX" but looking around with google I found a patch for that: https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1708301&group_… Then with the home made script I was still getting lots of socket errors in syslog, a colleague of mine fixed the openserunix.c ############################################################ --- openserunix.c.ori 2007-09-13 19:54:00.406861237 +0200 +++ openserunix.c 2007-09-13 19:54:07.407260167 +0200 @@ -97,6 +97,7 @@ goto err; } + from_len = sizeof(from); len = recvfrom(sock, buffer, BUF_SIZE, 0, (struct sockaddr*)&from, &from_len); if (len == -1) { fprintf(stderr, "Error in recvfrom: %s\n", strerror(errno)); ############################################################ maybe this is useful for someone since even the newest OpenSER version hast the "buggy" openserunix util :-) cheers, Patrick.

4 3

[OpenSER-Users] [presence] "in-dialog" SUBSCRIBE without "Route" record
by Iñaki Baz Castillo 14 Sep '07

14 Sep '07

Hi, I have presence in OpenSer same box. modparam("presence","server_address","sip:85.92.0.210") I've a problem because I get "in-dialog" SUBSCRIBE messages without "Route" header: When my SIP client (Twinkle or X-Lite) starts up it sends a SUBSCRIBE NOT-in-dialog: ---------------------------------------------------------------------------------------------------------- # U 2007/09/10 17:54:08.294012 222.21.235.18:5060 -> 85.92.0.210:5060 SUBSCRIBE sip:ibc@sip.domain.net SIP/2.0 Via: SIP/2.0/UDP 192.168.1.58;rport;branch=z9hG4bKcsmbires Max-Forwards: 70 To: <sip:ibc@sip.domain.net> From: "Angel" <sip:angel@sip.domain.net>;tag=wddxn Call-ID: bdrmoffsihrozyj(a)192.168.1.58 CSeq: 636 SUBSCRIBE Contact: <sip:angel@192.168.1.58> Accept: application/pidf+xml Event: presence Expires: 30 User-Agent: Twinkle/1.1alpha2 Content-Length: 0 # U 2007/09/10 17:54:08.296369 85.92.0.210:5060 -> 222.21.235.18:5060 SIP/2.0 202 OK Via: SIP/2.0/UDP 192.168.1.58;rport=5060;branch=z9hG4bKcsmbires;received=222.21.235.18 To: <sip:ibc@sip.domain.net>;tag=10.14184.1189439648.1 From: "Angel" <sip:angel@sip.domain.net>;tag=wddxn Call-ID: bdrmoffsihrozyj(a)192.168.1.58 CSeq: 636 SUBSCRIBE Expires: 30 Contact: <sip:85.92.0.210> Server: OpenSER (1.2.2-notls (i386/linux)) Content-Length: 0 # U 2007/09/10 17:54:08.297746 85.92.0.210:5060 -> 222.21.235.18:5060 NOTIFY sip:angel@222.21.235.18:5060 SIP/2.0 Via: SIP/2.0/UDP 85.92.0.210;branch=z9hG4bKfaad.3f308931.0 To: sip:angel@sip.domain.net;tag=wddxn From: sip:ibc@sip.domain.net;tag=10.14184.1189439648.1 CSeq: 2 NOTIFY Call-ID: bdrmoffsihrozyj(a)192.168.1.58 Content-Length: 342 User-Agent: OpenSER (1.2.2-notls (i386/linux)) Max-Forwards: 70 Event: presence Contact: <sip:85.92.0.210> Subscription-State: active;expires=30 Content-Type: application/pidf+xml ---------------------------------------------------------------------------------------------------------- And after 60 minutes (presence refresh in X-Lite) the following SUBSCRIBE from X-Lite is this sent. Note that: - This is a IN-DIALOG SUBSCRIBE (has totag and same callerd ID as before). - This in-dialog SUBSCRIBE hasn't "Route" header !!!!!!!!!!! ---------------------------------------------------------------------------------------------------------- # U 2007/09/10 17:54:35.390759 222.21.235.18:5060 -> 85.92.0.210:5060 SUBSCRIBE sip:85.92.0.210 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.58;rport;branch=z9hG4bKpgezzksl Max-Forwards: 70 To: <sip:ibc@sip.domain.net>;tag=10.14184.1189439648.1 From: "Angel" <sip:angel@sip.domain.net>;tag=wddxn Call-ID: bdrmoffsihrozyj(a)192.168.1.58 CSeq: 638 SUBSCRIBE Contact: <sip:angel@192.168.1.58> Accept: application/pidf+xml Event: presence Expires: 30 User-Agent: Twinkle/1.1alpha2 Content-Length: 0 ---------------------------------------------------------------------------------------------------------- So, because this second SUBSCRIBE hasn't a "Route" header the funcion "loose_route()" doesn't match it and it's routed as NOT-in-dialog message. So, what to do??? I've a in-dialog message without "Route" header, so it's not routed by "loose_route()". I've tryied with this: if (loose_route() || has_totag()) { but it generates a loop. Does OpenSer store the SUBSCRIBE dialog info for 60 minutes? could it recognize this establishd dialog? or should I route this in-dialog message as NOT in-dialog? Thanks for any explanation. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

1 1

[OpenSER-Users] About presence server in other host
by Iñaki Baz Castillo 14 Sep '07

14 Sep '07

Hi, I will separate the presence server in a different host, and I'd like to know your opinions: - For SUBSCRIBE messages main OpenSer will "rewriteuri(presence_serve)" and will NOT apply "record_route()" in order to avoid in-dialog NOTIFY to pass through main OpenSer. Is it ok? - "server_address" for Presence module will have: "sip:presence-server:5060" (of course presence module will just exist in presence-server). - Any other suggestion? In which cases is necessary to do this separation? with how much SIP traffic is it interesting? Thanks for any help. Regards. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

1 0

[OpenSER-Users] record_route_preset("x.x.x.x:5060; nat=yes"); and search("^Route:.*; nat=yes")
by Halomoan Chow 14 Sep '07

14 Sep '07

Dear All I don't understand why in the Openser+MediaProxy i need record_route_preset("x.x.x.x:5060;nat=yes"); and search("^Route:.*;nat=yes") What is the purpose while I can do client_nat_test to see if the request is come from a nat-ed client. If I remove search("^Route:.*;nat=yes") from below statement, I can do re-INVITE without any problem because it still have client_nat_test to find out the nat in between. if (client_nat_test("3") || search("^Route:.*;nat=yes")) { setbflag(6); use_media_proxy(); }; Hope someone can give me a clue. Thank you. Regards, Halomoan

2 5

Re: [OpenSER-Users] CANCEL generated by openser after SIP/SDP Status: 200 OK
by Jan ONDREJ (SAL) 14 Sep '07

14 Sep '07

On Thu, Sep 13, 2007 at 04:51:22PM +0200, Klaus Darilion wrote: > no - two: Right, my mistake. > Two identical NAPTR. One in RFC 3761 syntax and one in 2916 syntax. > Looks like enum_query() supports both syntax. Yes, it is my problem. I am sending this information for other users who will crawl this archive. :) > Solution 1: fix the NAPTR I sent request to their DNS administrators, it is not my site. > Solution 2: use enum_query("e164.arpa.","+sip"); (not sure about this one) I can confirm this. Works well before they update their DNS records. Thank you for help. SAL

1 0

Re[2]: [OpenSER-Users] OPTIONS problem
by Ion Minzu 14 Sep '07

14 Sep '07

Hello Bogdan-Andrei, Friday, September 14, 2007, 10:15:55 AM, you wrote: Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: SIP Request: Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: method: <OPTIONS> Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: uri: <sip:820999@voip.md> Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: version: <SIP/2.0> Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: parse_headers: flags=2 Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: Found param type 235, <rport> = <n/a>; state=17 Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: end of header reached, state=5 Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: parse_headers: Via found, flags=2 Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: parse_headers: this is the first via Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: After parse_msg... Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: preparing to run routing scripts... Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: parse_headers: flags=100 Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DEBUG:parse_to:end of header reached, state=9 Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DBUG:parse_to: display={}, ruri={sip:820999@voip.md} Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DEBUG: get_hdr_field: <To> [23]; uri=[sip:820999@voip.md] Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DEBUG: to body [sip:820999@voip.md ] Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: get_hdr_field: cseq <CSeq>: <1> <OPTIONS> Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DEBUG: get_hdr_body : content_length=0 Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DEBUG:maxfwd:is_maxfwd_present: value = 70 Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DEBUG: add_param: tag=gd60cu Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DEBUG:parse_to:end of header reached, state=29 Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DBUG:parse_to: display={}, ruri={sip:checksip@sheik:37176} Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: parse_headers: flags=200 Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: find_first_route: No Route headers found Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: loose_route: There is no Route HF Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: rewrite_uri: Rewriting Request-URI with 'sip:820999@172.17.6.103' Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: parse_headers: flags=ffffffffffffffff Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DEBUG: t_newtran: msg id=106 , global msg id=105 , T on entrance=0xffffffff Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: parse_headers: flags=ffffffffffffffff Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DEBUG:sl:sl_reply_error: error text is I'm terribly sorry, server error occurred (1/SL) Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: parse_headers: flags=ffffffffffffffff Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]:check_via_address(Y.Y.Y.Y, sheik, 0) Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DBG:sl:run_sl_callbacks: callback id 0 entered Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: trace_sl_onreply_out: ================================= Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: trace_sl_onreply_out: trace off... Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: DEBUG:destroy_avp_list: destroying list (nil) Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11708]: receive_msg: cleaning up Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11716]: DEBUG: timer routine:0,tl=0xb5e44354 next=0xb5e3bac8 Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11716]: DEBUG: timer routine:0,tl=0xb5e3bac8 next=(nil) Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11716]: DEBUG: timer routine:1,tl=0xb5e3bb34 next=(nil) Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11716]: DEBUG: timer routine:4,tl=0xb5e44344 next=0xb5e3bab8 Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11716]: DEBUG: timer routine:4,tl=0xb5e3bab8 next=(nil) Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11707]: SIP Request: Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11707]: method: <BYE> Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11707]: uri: <sip:X.X.X.X:5060;r2=on;lr=on;ftag=1455B87C-17C9> Sep 14 10:33:46 sip_proxy /usr/local/openser/sbin/openser[11707]: version: <SIP/2.0> > Hi, > Have you checked the openser logs to get more details about the error? > regards, > bogdan > Ion Minzu wrote: >> Hello , >> >> I have an working openser, i installed and configured in Nagios check_sip >> plugin, the problem is that openser answer to OPTIONS message with the error >> 500. >> Help me >> >> # >> U Y.Y.Y.Y:49813 -> X.X.X.X:5060 >> OPTIONS sip:820999@voip.md SIP/2.0 >> Via: SIP/2.0/UDP sheik:49813;rport >> From: sip:checksip@sheik:49813;tag=gd60cu >> To: sip:820999@voip.md >> Call-ID: dailgg@sheik >> CSeq: 1 OPTIONS >> Contact: sip:checksip@sheik:49813 >> Content-length: 0 >> Max-Forwards: 70 >> User-agent: check_sip 1.01 >> Accept: text/plain >> >> # >> U X.X.X.X:5060 -> Y.Y.Y.Y:49813 >> SIP/2.0 500 I'm terribly sorry, server error occurred (1/SL). >> Via: SIP/2.0/UDP sheik:49813;rport=49813;received=Y.Y.Y.Y. >> From: sip:checksip@sheik:49813;tag=gd60cu >> To: sip:820999@voip.md;tag=420087ba42f57437a013c6a41fc4e4c8.b0df >> Call-ID: dailgg@sheik >> CSeq: 1 OPTIONS >> Server: OpenSer (1.1.1-notls (i386/linux)). >> Content-Length: 0. >> >> >>

2 1

[OpenSER-Users] need help
by luhan 14 Sep '07

14 Sep '07

hi master-hand: i had rencontred a problem.when i configured my Openser work together with wesip,use two linux OS,one use to run openser,other run wesip, this is my configure file: openser: ------------------------------------ debug=9 # debug level (cmd line: -dddddddddd) fork=no log_stderror=yes # (cmd line: -E) children=8 # Uncomment these lines to enter debugging mode #fork=no #log_stderror=yes # port=5060 # uncomment the following lines for TLS support #disable_tls = 0 #listen = tls:your_IP:5061 #tls_verify_server = 1 #tls_verify_client = 1 #tls_require_client_certificate = 0 #tls_method = TLSv1 #tls_certificate = "/usr/local/etc/openser/tls/user/user-cert.pem" #tls_private_key = "/usr/local/etc/openser/tls/user/user-privkey.pem" #tls_ca_list = "/usr/local/etc/openser/tls/user/user-calist.pem" "openser.cfg" 154L, 3866C 14,1 Top # main routing logic route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); exit; }; # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!method=="REGISTER") record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (!uri==myself) { 61,1 49% }; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; route(2); } route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; exit; } route[2]{ if(!as_relay_t("app_server_one")){ t_reply("500","Application Server error"); } 121,3-17 98% } ----------------------------- and this is wesip: ----------------------------- <Server port="8005" shutdown="SHUTDOWN" debug="0"> <Service name="Tomcat-Standalone"> <Connector className="org.apache.catalina.connector.http.HttpConnector" port="8080" minProcessors="5" maxProcessors="75" enableLookups="true" acceptCount="10" debug="0" /> <Connector className="com.voztele.sipservlet.connector.SipConnector" minProcessors="5" maxProcessors="75" enableLookups="true" acceptCount="10" debug="0" addresses="localhost:5060" pathName="com.voztele" protocol="tcp" > <ExtraProperties> <Property key="javax.sip.SER_ADDRESS" value="192.168.7.15" /> <Property key="javax.sip.SER_PORT" value="5080" /> <Property key="STATISTICS" value="true" /> <Property key="javax.sip.STACK_NAME" value="app_server_one" /> <Property key="javax.sip.THREAD_POOL_SIZE" value="100" /> <Property key="javax.sip.THREAD_POOL_SIZE" value="100" /> <Property key="javax.sip.REENTRANT_LISTENER" value="true" /> <Property key="javax.sip.AUTOMATIC_DIALOG_SUPPORT" value="false" /> <Property key="javax.sip.TRACE_LEVEL" value="0" /> </ExtraProperties> </Connector> <Engine name="Standalone" defaultHost="localhost" debug="0" className="com.voztele.sipservlet.core.ConvergedEngine"> <Mapper className="org.apache.catalina.core.StandardEngineMapper" protocol="HTTP/1.1"/> ----------------------------------------------------------------------- at the debug model: found those tips: WARNING: using only the first listen address (no fork) 0(0) init_unixsock_socket: No unix domain socket will be opened ....... bind (Cannot assign requested address) -1(0) unable to open server sockets on dispatcher -1(0) ERROR:init_mod_child: Error while initializing module seas, rank 1 -1(0) main_dontfork: init_child failed would you help me! thank you very much. All my best regards. ------------------------------ (luhan china)卢涵技术部 E-mail: luhan(a)bjybkl.com phone: 010-59828003 mobile: 13810262476 ------------------------------

1 0

[OpenSER-Users] OPTIONS problem
by Ion Minzu 14 Sep '07

14 Sep '07

Hello , I have an working openser, i installed and configured in Nagios check_sip plugin, the problem is that openser answer to OPTIONS message with the error 500. Help me # U Y.Y.Y.Y:49813 -> X.X.X.X:5060 OPTIONS sip:820999@voip.md SIP/2.0 Via: SIP/2.0/UDP sheik:49813;rport From: sip:checksip@sheik:49813;tag=gd60cu To: sip:820999@voip.md Call-ID: dailgg@sheik CSeq: 1 OPTIONS Contact: sip:checksip@sheik:49813 Content-length: 0 Max-Forwards: 70 User-agent: check_sip 1.01 Accept: text/plain # U X.X.X.X:5060 -> Y.Y.Y.Y:49813 SIP/2.0 500 I'm terribly sorry, server error occurred (1/SL). Via: SIP/2.0/UDP sheik:49813;rport=49813;received=Y.Y.Y.Y. From: sip:checksip@sheik:49813;tag=gd60cu To: sip:820999@voip.md;tag=420087ba42f57437a013c6a41fc4e4c8.b0df Call-ID: dailgg@sheik CSeq: 1 OPTIONS Server: OpenSer (1.1.1-notls (i386/linux)). Content-Length: 0. -- Best regards, Ion Minzu, Specialist Tehnologii Informationale, I.S."Centrul de Telecomunicatii Speciale", tel:250-540, 820922 (office), 069501208 (mob), 382869185 (ICQ) mailto:ion.minzu@cts.md

2 1

[OpenSER-Users] Makefile "bug" in the latest 1.2.2 tarball...
by Geir O. Jensen 14 Sep '07

14 Sep '07

Hey, Downloaded the 1.2.2-tls tarball, extracted and did a make all - install. Everything seemed to work fine untill I tried to start it, whereupon it complained that tls was not built in. Looking at the Makefile I spotted the #TLS=1 - whence uncommented and rebuilt made everything a.o.k. I'm guessing if I did an export TLS=1 before make all it would also work? But when you give out a tarball that's supposed to include support for TLS I think I shouldn't need to do anything else than make all... Correct? So I'm calling this a bug :D // sip:gojensen@uninett.no | h323: 004710012 pstn: +47 73 55 79 23 | fax: +47 73 55 79 01

3 2

[OpenSER-Users] How to automate the new user registration process?
by lu 14 Sep '07

14 Sep '07

Hi all, Is there a simple way/opensource tool that can handle all the new VoIP users registration to the Server side automatically without human intervention/manual entry? iam using Openser 1.2 with Mysql 5.0 database. cheers.

2 1

[OpenSER-Users] Do most SIP devices support SRV DNS lookup?
by Iñaki Baz Castillo 14 Sep '07

14 Sep '07

Hi, I'd like to know about experiences using SRV DNS: - Do most SIP device support it? - Will I have unexpected surprises with some SIP phones or softphones because don't support it? - How often do the SIP devices supporting SRV have it enabled by default? Of course I will test it by myself, but I'd like to be warned about it :) Thanks for any response. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

2 1

[OpenSER-Users] tls errors
by Jeremy George 14 Sep '07

14 Sep '07

Hello All, I could use some help with tls. Any pointers to a possible solution would be greatly appreciated. Please let me know if any further information would be helpful. Thanks. Everything seems to register correctly. Openserctl ul show seems correct (see below.) For a short time all is well. I can call from/to Polycom hard phones. (Eyebeam never seems to make calls, though it does register correctly.) Then calls stop working, and I begin getting the following error messages. Sep 12 16:17:16 spongy openser[30644]: ERROR: tcp_blocking_connect: SO_ERROR (111) Connection refused Sep 12 16:17:16 spongy openser[30644]: ERROR: tcpconn_connect: tcp_blocking_connect failed Sep 12 16:17:16 spongy openser[30644]: ERROR: tcp_send: connect failed Sep 12 16:17:16 spongy openser[30644]: msg_send: ERROR: tcp_send failed Sep 12 16:17:16 spongy openser[30644]: ERROR:tm:t_forward_nonack: sending request failed Sep 12 16:17:53 spongy openser[30644]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled transaction Sep 12 16:17:53 spongy openser[30644]: ERROR:tm:w_t_relay: t_forward_nonack failed Sep 12 16:17:59 spongy openser[30629]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled transaction Sep 12 16:17:59 spongy openser[30629]: ERROR:tm:w_t_relay: t_forward_nonack failed Sep 12 16:18:25 spongy openser[30625]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled transaction Sep 12 16:18:25 spongy openser[30625]: ERROR:tm:w_t_relay: t_forward_nonack failed I thought the errors might be caused by an underlying tcp configuration issue on the machine, so I reconfigured the proxy and uas to use tcp (but not tls) and I had no trouble. Googling and looking through the archives seems to indicate I'm not the first person to have this problem. http://www.ip-phone-forum.de/archive/index.php/t-100539.html (I don't know if there is an answer here; unfortunately, I can't read German :) Spongy% sudo openser -V version: openser 1.2.2-tls (i386/linux) flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 2304 2007-05-25 16:36:07Z bogdan_iancu $ main.c compiled on 11:33:05 Sep 1 Spongy% sudo openserctl ul show Domain:: aliases table=512 records=0 max_slot=0 Domain:: location table=512 records=5 max_slot=1 AOR:: didama Contact:: sip:didama@75.56.10.117:37522;transport=tls Q= Expires:: 227 Callid:: acae15de-44fdabfd-e712aa40(a)75.56.10.117 Cseq:: 38 User-agent:: PolycomSoundPointIP-SPIP_330-UA/2.1.2.0049 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tls:128.91.3.19:5061 Methods:: 8063 AOR:: jeremy Contact:: sip:jeremy@75.56.10.115:5060;transport=udp Q= Expires:: 85 Callid:: 00036b09-50520002-40d733bc-0d83cc25(a)75.56.10.115 Cseq:: 140 User-agent:: Cisco-CP7960G/8.0 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: udp:128.91.3.19:5060 Methods:: 4294967295 AOR:: jessica Contact:: sip:jessica@75.56.10.116:55250;transport=tls Q= Expires:: 1196 Callid:: ef97ec67-46682f92-799b9cc1(a)75.56.10.116 Cseq:: 84 User-agent:: PolycomSoundPointIP-SPIP_650-UA/2.1.2.0078 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tls:128.91.3.19:5061 Methods:: 8063 AOR:: peggy Contact:: sip:peggy@75.56.10.113:1210;transport=TLS;rinstance=dd48392409b03c0a Q= Expires:: 3567 Callid:: M2NhMmI1OGZkZThhYjUzMmZiZTcxY2M0MjhlODE1ZDQ. Cseq:: 4 User-agent:: eyeBeam release 1013t stamp 43069 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tls:128.91.3.19:5061 Methods:: 5951 AOR:: helen Contact:: sip:helen@75.56.10.116:55250;transport=tls Q= Expires:: 1197 Callid:: f556d6ba-86bff9c9-f62d758c(a)75.56.10.116 Cseq:: 84 User-agent:: PolycomSoundPointIP-SPIP_650-UA/2.1.2.0078 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tls:128.91.3.19:5061 Methods:: 8063 Contact:: sip:helen@75.56.10.117:37522;transport=tls Q= Expires:: 228 Callid:: dd7e9645-83cfde68-f0f8341f(a)75.56.10.117 Cseq:: 38 User-agent:: PolycomSoundPointIP-SPIP_330-UA/2.1.2.0049 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tls:128.91.3.19:5061 Methods:: 8063 - Jeremy

2 1

[OpenSER-Users] 513 Massage too big
by Arya 14 Sep '07

14 Sep '07

Hello everyone I have a problem connecting to OpenSER from my public IP. I can connect and make calls to OpenSER inside my LAN but when I connect from outside LAN I get the 513 Massage too big massage. I than changed the openSER default config's section that checks a message size to a bigger number and I got the I get the "483 - too many Hops" error. I changed the config back to default and tested it with ngrep and I tried connecting to the server from a server in another state. The SIP server is on 192.168.1.109 and the computer trying to connect is on 192.168.1.100 And ngrep gave me these massages: Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 192.168.1.109:5060 -> 192.168.1.1:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.2d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 74.13.124.71:5060 -> 192.168.1.109:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.2d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 192.168.1.109:5060 -> 192.168.1.1:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 74.13.124.71:5060 -> 192.168.1.109:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 192.168.1.109:5060 -> 192.168.1.1:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 74.13.124.71:5060 -> 192.168.1.109:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 192.168.1.109:5060 -> 192.168.1.1:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 74.13.124.71:5060 -> 192.168.1.109:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 192.168.1.109:5060 -> 67.186.60.123:29296 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.3d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.2d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 192.168.1.109:5060 -> 192.168.1.1:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.3d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.2d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.fc407ae2.0. Via: SIP/2.0/UDP 192.168.15.100:29296;received=67.186.60.123 ;branch=z9hG4bK-d87543-ce4dd823475b2c25-1--d87543-;rport=29296. To: "100"<sip:100@74.13.124.71>;tag=329cfeaa6ded039da25ff8cbb8668bd2.3724. From: "100"<sip:100@74.13.124.71>;tag=6c4a5976. Call-ID: Y2NhNzExOWI4ODViYjc2NjJlMTUxOGYwNTUxMTYxNDk.. CSeq: 1 REGISTER. Server: OpenSER (1.2.2-notls (i386/linux)). Content-Length: 0. . # U 74.13.124.71:5060 -> 192.168.1.109:5060 SIP/2.0 513 Message too big. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.3d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.2d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.1d407ae2.0. Via: SIP/2.0/UDP 192.168.1.109;received=192.168.1.1;branch= z9hG4bKcf61.0d407ae2.0. -- Thank You

4 6

Re: [OpenSER-Users] CANCEL generated by openser after SIP/SDP Status: 200 OK
by Jan ONDREJ (SAL) 13 Sep '07

13 Sep '07

Hello, On Wed, Sep 12, 2007 at 05:32:15PM +0200, Klaus Darilion wrote: > 1. I have forgotten to tell you to use the "-W byline" switch too in > ngrep (much more readable SIP logs) I can resend you new logs if needed. > 2. Nevertheless, I have found the error: In the openser proxy your > create a second branch: Take a look at the logs - there are 2 INVITEs > sent from openser to ser - the only different in these INVITEs is the > branch parameter in the topmost Via header. > > The first is: > branch=z9hG4bK41a.25464943.0 > the second is: > branch=z9hG4bK41a.25464943.1 > > Thus, openser does parallel forking. Then, when Grandstream answers the > second branch (branch=z9hG4bK41a.25464943.1) openser will CANCEL the > first branch. Right. There is no problem with CANCEL but with 2 INVITEs. I have this in my openser log: 2(13970) DEBUG: t_lookup_request: no transaction found 2(13970) DBG: trans=0xb60d6e80, callback type 1, id 1 entered 2(13970) DEBUG:dialog:build_new_dlg: new dialog on hash 2386 2(13970) DBG: trans=0xb60d6e80, callback type 1, id 0 entered Is this a right place where the second fork is done? > Thus, you have either bug in your config or in your provisioning (maybe > you have the user twice in alias table or location table). Which command can create this second INVITE? What I need to find in my config? This user is not local, it is found by ENUM. My ENUM configuration: if (uri=~"^sip:\+[0-9]+@") { if (enum_query("e164.arpa.")) { xlog("L_ERR", "ENUM[e164.arpa]: [$rm] from user $fu to $ru\n"); route(5); return; }; if (enum_query("e164.arpa.", "voice")) { route(5); return; }; if (enum_query("e164.bts.sk.")) { route(5); return; }; }; Thanks. SAL

2 2

[Serusers] FW: problem in DNS lookup from enum
by geethanjali.csg＠wipro.com 13 Sep '07

13 Sep '07

Hi, I am configuring ser to use enum module. I am getting this error when dns lookup is done from ser. 0(27798) get_record: lookup(8.7.6.e164.arpa, 35) failed 0(27798) enum_query(): No NAPTR record found for 8.7.6.e164.arpa. This is my zone file: $TTL 3D @ IN SOA e164.arpa. root( 4 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN NS localhost IN NS e164.arpa. localhost A 127.0.0.1 e164.arpa. A 10.200.220.200 $ORIGIN 1.2.3.4.e164.arpa. IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:abcd@e164.arpa!" . $ORIGIN 8.7.6.e164.arpa. IN NAPTR 20 100 "u" "E2U+sip" "!^.*$!sip:xyz@e164.arpa!" . named.conf file contains, zone "e164.arpa" IN { type master; file "/var/named/named.enum"; }; This is my enum code in ser.cfg. loadmodule "/usr/local/lib/ser/modules/enum.so" modparam("enum", "domain_suffix", "e164.arpa.") if (method == "INVITE" && uri =~ "sip:\+[0-9]*+@.") { if (enum_query("e164.arpa")) { route(1); }; }; Its possible to ping the domain e164.arpa from the m/c where ser is installed. Any help in this regard is appreciated. Regards Geethanjali The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

1 0

[OpenSER-Users] Installing OpenSER in multiprocessor machine
by John Barry 13 Sep '07

13 Sep '07

Hello, I would like to know if there are any especial considerations when compiling, configuring, and running OpenSER v1.2.2 in a multiprocessor machine. I am using a quad-processor machine (Intel Xeon @ 3.00GHz) with Red Hat Enterprise Linux AS release 4 (2.6.9-42.0.3.ELsmp #1 SMP x86_64 x86_64 x86_64 GNU/Linux). I am also using MySQL DB for authentication in the same machine. I will appreciate any advice or information. Bests, JB _________________________________________________________________ Check out some new online services at Windows Live Ideas—so new they haven’t even been officially released yet. http://ideas.live.com

2 1

[Serusers] problem in DNS lookup from enum
by geethanjali.csg＠wipro.com 13 Sep '07

13 Sep '07

Hi, I am configuring ser to use enum module. I am getting this error when dns lookup is done from ser. 0(27798) get_record: lookup(8.7.6.e164.arpa, 35) failed 0(27798) enum_query(): No NAPTR record found for 8.7.6.e164.arpa. This is my zone file: $TTL 3D @ IN SOA e164.arpa. root( 4 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN NS localhost IN NS e164.arpa. localhost A 127.0.0.1 e164.arpa. A 10.200.220.200 $ORIGIN 1.2.3.4.e164.arpa. IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:abcd@e164.arpa!" . $ORIGIN 8.7.6.e164.arpa. IN NAPTR 20 100 "u" "E2U+sip" "!^.*$!sip:xyz@e164.arpa!" . named.conf file contains, zone "e164.arpa" IN { type master; file "/var/named/named.enum"; }; This is my enum code in ser.cfg. loadmodule "/usr/local/lib/ser/modules/enum.so" modparam("enum", "domain_suffix", "e164.arpa.") if (method == "INVITE" && uri =~ "sip:\+[0-9]*+@.") { if (enum_query("e164.arpa")) { route(1); }; }; Its possible to ping the domain e164.arpa from the m/c where ser is installed. Any help in this regard is appreciated. Regards Geethanjali The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

1 0

Re: [Serusers] WARNING: xl_mod_init: more IP 10.0.0.21 not used and ERROR: init_tcpudp_sock: bind: Address already in use [98]
by Jiri Kuthan 13 Sep '07

13 Sep '07

At 11:55 12/09/2007, Frank Wang wrote: >I downloaded ser 2.0.0-rc1 source code from <http://www.iptel.org/ser_2_0_0_release_candidate_1>http://www.iptel.org/ser_2_0_0_release_candidate_1 and install on my Linux step by step according the tutorial on the WEB. > >When I running SER, I got follow messages: > >[root@sipmcu ser]# ../../sbin/ser -f ser.cfg >Listening on > udp: <http://10.0.0.21>10.0.0.21 [<http://10.0.0.21>10.0.0.21]:5060 > tcp: <http://10.0.0.21>10.0.0.21 [<http://10.0.0.21>10.0.0.21]:5060 >Aliases: > tcp: <http://sipmcu.leadtek.com.cn:5060>sipmcu.leadtek.com.cn:5060 > udp: <http://sipmcu.leadtek.com.cn:5060>sipmcu.leadtek.com.cn:5060 > *: mytestser.org:* > >WARNING: no fork mode > 0(3078) init_tcp: using epoll_lt as the io watch method (auto detected) > 0(3078) Maxfwd module- initializing > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used unimportant. (I checked the code and I was a bit puzzled by it, but it really shold not matter much.) > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) WARNING: xl_mod_init: more IP <http://10.0.0.21>10.0.0.21 not used > 0(3078) ERROR: init_tcpudp_sock: bind: Address already in use [98] This is the problem. Maybe you have a SER instance running from the last time and you are starting the script again, for which reason SER can't be restarted -- it can't claim the same port number twice. > 0(3078) ERROR: ctl: mod_init: init ctrl. sockets failed > 0(3078) init_mod(): Error while initializing module ctl >ERROR: error while initializing modules This could have same reason. > >could anybody tell me how about it? Thanks a lot. > >Regards, >Frank >_______________________________________________ >Serusers mailing list >Serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers -- Jiri Kuthan http://iptel.org/~jiri/

2 2

Re: [OpenSER-Users] WeSIP with openser 1.2.0 again
by Elias Baixas 13 Sep '07

13 Sep '07

Hi Gregorio, posting the SIP message that caused the problem would help me reproduce it, also some OpenSER logs would help. It seems to be related to the binary-encoding of the message. try out sipSpy to capture messages if you like. remove any field which you find confidential (lest Max-Forwards...) from the SIP message send it to me privately if you want. regards, Elias Gregorio wrote: > > Hi everyone, > > > > Hi! > > Just installed WeSIP beta-0.1.4 and openser 1.2.0 in the same machine, > configuration looks alright because some SIP Servlets receive > messages. Now I am getting an exception in the SEAS module when I > receive MESSAGE, I think this problem is similar to a previous one in > the mailing list (Sat Apr 28 16:07:34 CEST 2007, [WeSIP with openser > 1.2.0 again]). Does someone know anything about it? > > > > This is the exception: > > > > Thanks for helping. > > > > java.lang.ArrayIndexOutOfBoundsException: 5942 > > at com.voztele.seas.SeasMsg.getNboShort(SeasMsg.java:40) > > at > com.voztele.javax.sip.header.SIPHeader.<init>(SIPHeader.java:144) > > at > com.voztele.javax.sip.header.MaxForwards.<init>(MaxForwards.java:29) > > at > com.voztele.javax.sip.message.SIPMessage.createSIPHeader(SIPMessage.java:266) > > at > com.voztele.javax.sip.message.SIPMessage.addSIPHeader(SIPMessage.java:230) > > at > com.voztele.javax.sip.message.SIPMessage.<init>(SIPMessage.java:225) > > at > com.voztele.javax.sip.message.SIPResponse.<init>(SIPResponse.java:338) > > at > com.voztele.javax.sip.parser.StringMsgParser.parseSERMessage(StringMsgParser.java:357) > > at > com.voztele.seas.SeasMessageEvent.getSIPMessage(SeasMessageEvent.java:136) > > at > com.voztele.seas.SeasTransactionEvent.getSIPMessage(SeasTransactionEvent.java:70) > > at > com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301) > > at java.lang.Thread.run(Thread.java:595) > > Exception in thread "ExpressMChannel[1]" java.lang.NullPointerException > > at > com.voztele.seas.SeasMessageEvent.getSIPMessage(SeasMessageEvent.java:143) > > at > com.voztele.seas.SeasTransactionEvent.getSIPMessage(SeasTransactionEvent.java:70) > > at > com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301) > > at java.lang.Thread.run(Thread.java:595) > > java.lang.ArrayIndexOutOfBoundsException: 5942 > > at com.voztele.seas.SeasMsg.getNboShort(SeasMsg.java:40) > > at > com.voztele.javax.sip.header.SIPHeader.<init>(SIPHeader.java:144) > > at > com.voztele.javax.sip.header.MaxForwards.<init>(MaxForwards.java:29) > > at > com.voztele.javax.sip.message.SIPMessage.createSIPHeader(SIPMessage.java:266) > > at > com.voztele.javax.sip.message.SIPMessage.addSIPHeader(SIPMessage.java:230) > > at > com.voztele.javax.sip.message.SIPMessage.<init>(SIPMessage.java:225) > > at > com.voztele.javax.sip.message.SIPResponse.<init>(SIPResponse.java:338) > > at > com.voztele.javax.sip.parser.StringMsgParser.parseSERMessage(StringMsgParser.java:357) > > at > com.voztele.seas.SeasMessageEvent.getSIPMessage(SeasMessageEvent.java:136) > > at > com.voztele.seas.SeasTransactionEvent.getSIPMessage(SeasTransactionEvent.java:70) > > at > com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301) > > at java.lang.Thread.run(Thread.java:595) > > Exception in thread "ExpressMChannel[2]" java.lang.NullPointerException > > at > com.voztele.seas.SeasMessageEvent.getSIPMessage(SeasMessageEvent.java:143) > > at > com.voztele.seas.SeasTransactionEvent.getSIPMessage(SeasTransactionEvent.java:70) > > at > com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301) > > at java.lang.Thread.run(Thread.java:595) > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users >

1 0

[OpenSER-Users] redirect server and handling 302 messages
by erik.linder＠accenture.com 12 Sep '07

12 Sep '07

Hello, I'm trying to make openser process 302 messages though I have problems(part of .cfg file below). I'll briefly explain the call flow I'd like to have: UA1 ---INVITE---> Session border controller ---INVITE--->SIP PROXY1 SIP PROXY1---INVITE--->REDIRECT SERVER---302 MOVED--->SIP PROXY1 SIP PROXY1---INVITE--->SIP PROXY2---INVITE---> Session border controller---INVITE---> UA2 This is how I want it to work. However managed to get a weird call flow were the 302 is forwarded back to the session border controller by the proxy1 which then trigger an INVITE sent to the SIP proxy2. But that is not what I want. My 302 message looks like this 20:12:34.314705 IP 192.168.200.101.sip > 192.168.200.102.sip: SIP, length: 488 E.....@.@.%....e...f........SIP/2.0 302 Moved temporarily Via: SIP/2.0/UDP 192.168.200.102;branch=z9hG4bK1658.2543f3d6.0 Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bKpis9m130dgj04b08v7k1.1 To: "22222"<sip:22222@btsip.bt.com>;tag=cc0e227ef05fff2dd833db745f3905a6.25f 2 From: "111"<sip:11111@btsip.bt.com>;tag=SDvto0501-df614a6e Call-ID: SDvto0501-515b91532ff7927a8345f39add52762f-06ahc50 CSeq: 1 INVITE Contact: , sip:22222@mydomain.com;maddr=192.168.200.103:5060;side=term> Content-Length: 0 192.168.200.101 is redirect server 192.168.200.102 is the proxy1 192.168.200.103 is proxy2 192.168.200.10 is session border controller 1. I would like to have proxy1 process the 302 message but there seems (from other mails on the mailing list) that openser does not allow routing depending on maddr in the Contact field. Sic :-( <- how can this routing decision been taken , using rewritehostport after get_redirect("*") is kind of ignored. The only workaround I have is to change the mydomain.com to the IP of proxy2 to get the automatic redirect 2. How can I block the redirect to the session border controller and send an invite right away to the proxy2? Here are the relevant part of the logic I use in proxy1 to handle the 302 I'm using this to trigger the forward to the redirect server: lookup("aliases"); #dest is remote if (!lookup("location")) { t_on_failure("3"); xlog("L_INFO","redirect invite to SLS\n"); #change orig to term in request URI $avp(s:request_uri_to_use)=$ru; avp_subst("$avp(s:request_uri_to_use)", "/orig/term/"); avp_pushto("$ru","$avp(s:request_uri_to_use)"); #forward("udp:192.168.200.101:5060"); #exit; rewritehostport("192.168.200.101:5060"); if(!t_relay()) { sl_reply_error(); } return; and this to try to handle the 302 that is received but it does not behave like I want: failure_route[3] { xlog("L_WARN","redirect FAILUREROUTE: time_t=$Ts messageid=$mi remark=here we are $bR\n"); if(t_check_status("3[0-9][0-9]")) { get_redirects("*"); xlog("L_WARN","^method=$rm ^ruri=$ru ^messageid=$mi^remark=2status is 3xx\n--$br--\nbR((($bR)))\n"); #rewritehost("$(ru{uri.maddr})"); serialize_branches(0); } xlog("L_WARN","nextbranch\n"); #next_branches(); #t_on_failure("3"); #t_relay(); return; #t_reply("404", "No branches left"); } Help would be appreciated Cheers erik This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

2 2

[OpenSER-Users] authorization problems with multiple servers
by Ben Smithurst 12 Sep '07

12 Sep '07

Hi We have a problem with clients authorizing (whether for INVITE or REGISTER) against a pair of openser servers, served via either round robin A records, or multiple equal preference SRV records. The problem in a nutshell is client sends INVITE to server 1 server 1 replies with authorization challenge client sends INVITE with auth to server 2 server 2 doesn't like the 'nonce' value Now, this only happens via our nat proxy, as far as we can tell, so I think the problem lies there (and I have contacted the vendor of that system). However I wonder if there is any way to make openser work in such a setup, in case other client do the same thing (which IMO is quite a stupid thing to do) ... would the valid 'nonce' values need to be stored in the DB? Incidentally we are using mysql authentication and we are using usrloc in db_mode 3, with both openser machines pointed at the same mysql server. We're using a pretty recent openser SVN revision (dev15). Any tips would be appreciated. thanks -ben -- Ben Smithurst http://www.bensmithurst.com/

2 3

[OpenSER-Users] WeSIP with openser 1.2.0 again
by Gregorio 12 Sep '07

12 Sep '07

Hi everyone, Hi! Just installed WeSIP beta-0.1.4 and openser 1.2.0 in the same machine, configuration looks alright because some SIP Servlets receive messages. Now I am getting an exception in the SEAS module when I receive MESSAGE, I think this problem is similar to a previous one in the mailing list (Sat Apr 28 16:07:34 CEST 2007, [WeSIP with openser 1.2.0 again]). Does someone know anything about it? This is the exception: Thanks for helping. java.lang.ArrayIndexOutOfBoundsException: 5942 at com.voztele.seas.SeasMsg.getNboShort(SeasMsg.java:40) at com.voztele.javax.sip.header.SIPHeader.<init>(SIPHeader.java:144) at com.voztele.javax.sip.header.MaxForwards.<init>(MaxForwards.java:29) at com.voztele.javax.sip.message.SIPMessage.createSIPHeader(SIPMessage.java:266 ) at com.voztele.javax.sip.message.SIPMessage.addSIPHeader(SIPMessage.java:230) at com.voztele.javax.sip.message.SIPMessage.<init>(SIPMessage.java:225) at com.voztele.javax.sip.message.SIPResponse.<init>(SIPResponse.java:338) at com.voztele.javax.sip.parser.StringMsgParser.parseSERMessage(StringMsgParser .java:357) at com.voztele.seas.SeasMessageEvent.getSIPMessage(SeasMessageEvent.java:136) at com.voztele.seas.SeasTransactionEvent.getSIPMessage(SeasTransactionEvent.jav a:70) at com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301) at java.lang.Thread.run(Thread.java:595) Exception in thread "ExpressMChannel[1]" java.lang.NullPointerException at com.voztele.seas.SeasMessageEvent.getSIPMessage(SeasMessageEvent.java:143) at com.voztele.seas.SeasTransactionEvent.getSIPMessage(SeasTransactionEvent.jav a:70) at com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301) at java.lang.Thread.run(Thread.java:595) java.lang.ArrayIndexOutOfBoundsException: 5942 at com.voztele.seas.SeasMsg.getNboShort(SeasMsg.java:40) at com.voztele.javax.sip.header.SIPHeader.<init>(SIPHeader.java:144) at com.voztele.javax.sip.header.MaxForwards.<init>(MaxForwards.java:29) at com.voztele.javax.sip.message.SIPMessage.createSIPHeader(SIPMessage.java:266 ) at com.voztele.javax.sip.message.SIPMessage.addSIPHeader(SIPMessage.java:230) at com.voztele.javax.sip.message.SIPMessage.<init>(SIPMessage.java:225) at com.voztele.javax.sip.message.SIPResponse.<init>(SIPResponse.java:338) at com.voztele.javax.sip.parser.StringMsgParser.parseSERMessage(StringMsgParser .java:357) at com.voztele.seas.SeasMessageEvent.getSIPMessage(SeasMessageEvent.java:136) at com.voztele.seas.SeasTransactionEvent.getSIPMessage(SeasTransactionEvent.jav a:70) at com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301) at java.lang.Thread.run(Thread.java:595) Exception in thread "ExpressMChannel[2]" java.lang.NullPointerException at com.voztele.seas.SeasMessageEvent.getSIPMessage(SeasMessageEvent.java:143) at com.voztele.seas.SeasTransactionEvent.getSIPMessage(SeasTransactionEvent.jav a:70) at com.voztele.seas.ExpressMessageChannel.run(ExpressMessageChannel.java:301) at java.lang.Thread.run(Thread.java:595)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users