sr-users September 2007

sr-users@lists.kamailio.org

158 participants
247 discussions

[OpenSER-Users] [presence] "in-dialog" SUBSCRIBE without "Route" record

by Iñaki Baz Castillo

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

16 years, 11 months

[OpenSER-Users] About presence server in other host

by Iñaki Baz Castillo

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

16 years, 11 months

[OpenSER-Users] record_route_preset("x.x.x.x:5060; nat=yes"); and search("^Route:.*; nat=yes")

by Halomoan Chow

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

16 years, 11 months

Re: [OpenSER-Users] CANCEL generated by openser after SIP/SDP Status: 200 OK

by Jan ONDREJ (SAL)

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

16 years, 11 months

Re[2]: [OpenSER-Users] OPTIONS problem

by Ion Minzu

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

16 years, 11 months

[OpenSER-Users] need help

by luhan

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

16 years, 11 months

[OpenSER-Users] OPTIONS problem

by Ion Minzu

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

16 years, 11 months

[OpenSER-Users] Makefile "bug" in the latest 1.2.2 tarball...

by Geir O. Jensen

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

16 years, 11 months

[OpenSER-Users] How to automate the new user registration process?

by lu

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.

16 years, 11 months

[OpenSER-Users] Do most SIP devices support SRV DNS lookup?

by Iñaki Baz Castillo

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

16 years, 11 months

← Newer
1
...
14
15
16
17
18
19
20
...
25
Older →

Jump to page:

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