sr-users September 2007

sr-users@lists.kamailio.org

158 participants
248 discussions

[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

[OpenSER-Users] Wanted: VoIP Engineer for Warsaw !
by laurent schweizer 12 Sep '07

12 Sep '07

Peoplefone AG offers Voice over IP(VoIP) services with exceptional rates. Peoplefone is a certified partner of Siemens<http://www.siemens.ch/index.jsp?sdc_p=c175fi1012637lmno1012637psuz1&sdc_sid…>and AVM/FRITZ!Box <http://www.fritz-shop.ch/>. Due to our rapid growth, for our new Polish subsidiary we are currently seeking for: VOIP SPECIALIST Place of work: Warsaw *Requirements:* - Graduation from college or university with a Bachelor's degree (preferably IT) - Experience with PHP - Practical knowledge of C and C++ - Practical knowledge of Mysql and Postgresql - Linux experience - Knowledge of IP Networks, UDP, TCP - Experience with tools for Network analysis like Ethereal - VoIP basic knowledge, VoIP servers, configuration of devices - Fluency in English - Ability to interact with individuals and groups at all levels - Detail oriented and analytical - Strong verbal and written communication skills Knowledge of Perl, Java, Asterisk / SER / OPENSER, ability to configure routers, Cisco or Patton gateways, knowledge of SIP and STUN protocol, knowledge of NAT problems, of outbandProxy, knowledge of monitoring tools like Cactus, Nagios, MRTG or high availability tools like DRBD, Hearthbeat would be an additional asset. Interested individuals are requested to send their resume to: ewa.ciesla(a)peoplefone.com In your application please put the following statement: I hereby agree for processing the following personal information strictly for recruitment purposes in accordance with the regulation regarding the protection of personal data passed on the following date: 29.08.97r. Dz.U nr 133 poz. 883.

1 0

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

12 Sep '07

Hello, I have problems calling from my phones connected to openser to grandstream phones on another university to ser. Problem is, that my openser generates a "CANCEL" SIP packet sent to grandstream phone, but no CANCEL received from my phone. Wireshark shows something like this: 1189587144.843962 158.195.15.100 -> 158.197.16.77 SIP/SDP Status: 200 OK, with session description 1189587144.845528 158.197.16.77 -> 158.195.15.100 SIP Request: CANCEL sip:+421xxxx44903@domain.sk 1189587144.853654 158.195.15.100 -> 158.197.16.77 SIP Status: 200 canceling Communication before is OK. 158.197.16.77 is my openser server and 158.195.15.100 is peers phone. Any idea, why openser can generate this packet? Can openser generate a SIP packet not received from client? Calling from my phone to another phone on same university works well. Thank you. SAL

3 4

[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 Frank Wang 12 Sep '07

12 Sep '07

I downloaded ser 2.0.0-rc1 source code from 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: 10.0.0.21 [10.0.0.21]:5060 tcp: 10.0.0.21 [10.0.0.21]:5060 Aliases: tcp: sipmcu.leadtek.com.cn:5060 udp: 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 10.0.0.21 not used 0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used 0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used 0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used 0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used 0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used 0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used 0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used 0(3078) WARNING: xl_mod_init: more IP 10.0.0.21 not used 0(3078) ERROR: init_tcpudp_sock: bind: Address already in use [98] 0(3078) ERROR: ctl: mod_init: init ctrl. sockets failed 0(3078) init_mod(): Error while initializing module ctl ERROR: error while initializing modules could anybody tell me how about it? Thanks a lot. Regards, Frank

1 0

Fwd: [OpenSER-Users] Transaction Deletion
by Brandon Armstead 12 Sep '07

12 Sep '07

---------- Forwarded message ---------- From: Brandon Armstead <brandon.armstead(a)gmail.com> Date: Sep 7, 2007 12:06 PM Subject: Re: [OpenSER-Users] Transaction Deletion To: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> Hello Bodgan, There is no noticable delay however the only thing I see is that one of the RR'ed proxy's responds sends out 200 OK rather than the original. You can see an example sipcap of this at this url: http://pastebin.ca/685897 . If you could let me know if you see anything that looks rather, odd, towards the end you can see the last few transactions and where there is no response to 216.82.224.203's 200 OK, where it flips from 216.82.224.202 to 216.82.224.203 from the RR. Also then later the PSTN follows with a BYE, due to no response, once again thanks for your help! Regards, Brandon On 9/7/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote: > > Hi Brandon, > > Is there any noticeable delay between the 200OK and ACK ? > > regards, > bogdan > > Brandon Armstead wrote: > > Hello Users, > > > > I have a weird scenario where the PSTN is responding with 200 OK, > > however Openser Never forwards on the ACK, after several > > retransmissions of 200OK to Openser, PSTN responds with BYE, anyone > > know what might be going on? I've played with the timers to no avail, > > any help is appreciated, thank you! The log below is as follows: > > > > 375 Sep 6 12:18:10 openser /usr/local/sbin/openser[17385]: DEBUG: > > timer routine:1,tl=0x2b78e4e73588 next=(nil), timeout=261 > > 376 Sep 6 12:18:11 openser /usr/local/sbin/openser[17385]: DEBUG: > > timer routine:2,tl=0x2b78e4e733b8 next=(nil), timeout=262 > > 377 Sep 6 12:18:11 openser /usr/local/sbin/openser[17385]: DEBUG: > > wait_handler : removing 0x2b78e4e73338 from table > > 378 Sep 6 12:18:11 openser /usr/local/sbin/openser[17385]: DEBUG: > > delete transaction 0x2b78e4e73338 > > 379 Sep 6 12:18:11 openser /usr/local/sbin/openser[17385]: DEBUG: > > wait_handler : done > > 380 Sep 6 12:18:12 openser /usr/local/sbin/openser[17345]: > > DEBUG:parse_to:end of header reached, state=10 > > 381 Sep 6 12:18:12 openser /usr/local/sbin/openser[17345]: DEBUG: > > get_hdr_field: <To> [26]; uri=[sip:openser] > > 382 Sep 6 12:18:12 openser /usr/local/sbin/openser[17345]: DEBUG: to > > body [<sip:openser> ] > > 383 Sep 6 12:18:12 openser /usr/local/sbin/openser[17345]: DEBUG: > > get_hdr_body : content_length=0 > > 384 Sep 6 12:18:12 openser /usr/local/sbin/openser[17345]: > > DEBUG:destroy_avp_list: destroying list (nil) > > 385 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: > > DEBUG:forward_reply: found module tm, passing reply to it > > 386 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG: > > t_check: start=0xffffffffffffffff > > 387 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG: > > add_param: tag=gK0288a919 > > 388 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: > > DEBUG:parse_to:end of header reached, state=29 > > 389 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG: > > get_hdr_field: <To> [53]; uri=[ sip:17144828306@openser] > > 390 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG: to > > body [<sip:17144828306@openser>] > > 391 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG: > > t_reply_matching: hash 53903 label 1526431020 branch 0 > > 392 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG: > > t_reply_matching: no matching transaction exists > > 393 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG: > > t_reply_matching: failure to match a transaction > > 394 Sep 6 12:18:14 openser /usr/local/sbin/openser[17343]: DEBUG: > > t_check: end=(nil) > > > > It seems like its not matching the transaction, because a timer is > > removing the transaction? Any ideas? Thanks! > > -- > > Brandon Armstead > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > Users(a)openser.org > > http://openser.org/cgi-bin/mailman/listinfo/users > > > > -- Brandon Armstead -- Brandon Armstead

2 1

Re: [OpenSER-Users] 513 Massage too big
by Bogdan-Andrei Iancu 12 Sep '07

12 Sep '07

Arya, it means you have a routing error in the script - you need to debug your script to see where the routing logic is broken - try using xlog() messages to see the execution path of your script. I cannot help you with more than this. regards, bogdan Arya wrote: > any idea how I can fix the problem? > > On 9/11/07, *Arya* <arya6000(a)gmail.com <mailto:arya6000@gmail.com>> > wrote: > > I used ngrep but it just shows that the massage keeps bouncing > server to client, and eventually it says massage too big > > > On 9/11/07, * Bogdan-Andrei Iancu* < bogdan(a)voice-system.ro > <mailto:bogdan@voice-system.ro>> wrote: > > Hi, > > use ngrep or tcpdump to get a network trace from the proxy > server, on > the loopback interface. > > Regards, > Bogdan > > Arya wrote: > > Can you tell me how I can trace it? could this be an issue > with my > > router? its the Linksys Wr54G and its set on DMZ to the server > > > > On 9/10/07, *Bogdan-Andrei Iancu * <bogdan(a)voice-system.ro > <mailto:bogdan@voice-system.ro> > > <mailto: bogdan(a)voice-system.ro > <mailto:bogdan@voice-system.ro>>> wrote: > > > > Hi Arya, > > > > I suspect you have a routing problem that cause the > request to loop on > > openser (via loopback interface) - openser keeps sending the > > request to > > itself. That's why you get a "Message to big" or "too > many hops".... > > > > run a trace on lo to see if this is what's happening. > > > > regards, > > bogdan > > > > Arya wrote: > > > 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 > <http://192.168.1.109> <http://192.168.1.109 > <http://192.168.1.109>> > > <http://192.168.1.109> and the > > > computer trying to connect is on 192.168.1.100 > <http://192.168.1.100> > > < http://192.168.1.100> <http://192.168.1.100 < > http://192.168.1.100>> > > > > > > And ngrep gave me these massages: >

1 0

[OpenSER-Users] 'while' statement in config file
by Daniel-Constantin Mierla 12 Sep '07

12 Sep '07

Hello, although is more part of devel, the decision will affect users of future stable releases, so I posted on both lists. Maybe some of you noticed that in the ongoing process of improving the pseudo-variables system, the AVPs and HDRs can be accessed with dynamic index. That means next lines are correct in the config file. $var(i) = 1; xlog("$(avp(i:20)[$var(i)])"); if($(avp(i:20)[$var(i)]) == 3) { } In the past, the index was static, as a number. The question I want to address is whether makes sense to add 'while' statements to iterate through avps or hdrs. More or less, the cycles can be done via recursive routes. The block: $var(i) = 0; while($(avp(i:20)[$var(i)]) != null) { ..... $var(i) = $var(i) +1; } is equivalent with: $var(i) = 0; route(1); .... route[1] { if(($(avp(i:20)[$var(i)]) == null) return; ... $var(i) = $var(i) +1; route(1); } 'while' may look more attractive, but could open the pandora box, people asking for more and more, that will turn config language is something very complex (not saying that is simple now :-) ). The drawback with recursive routes is the fixed number of routes that can be defined with the standard openser: 40 (number can be increased if openser is recompiled), because for each cycle another route has to be used. Waiting for your opinions... Cheers, Daniel

3 2

[OpenSER-Users] add/remove headers and append_branch
by Madalina Pitis 12 Sep '07

12 Sep '07

Hello, I have a problem trying to remove a header using remove_hf() after an append_branch(). I am using 1.2 version of OpenSer. The scenario with the problem is as described in the folowing lines. When I receive an INVITE I try a parallel fork (one leg towards PSTN, the other towards IP), at which time I append a "Redirection" header. The PSTN leg will be answered with a 486 response, due to the presence of the "Redirection" header. When the IP leg expires, I receive a 408 response, at which time I do a serial fork, and resend the message towards the PSTN destination, this time without the "Redirection" header. The problem is that I cannot seem to be able to remove (or find) the header. I tried everywhere (before appending the new branch, after, in branch_route, before relaying), as you will see below. I tried searching the mailing lists but nothing turned up. I would greatly appreciate any help, for I am running out of ideas. Here is a simplified version of my configuration script, containing only the significant bits of the routing blocks: #--------------------------------------------------- # main routing logic #--------------------------------------------------- route { # check maxfwd and message lenght # do loose routing if (method=="INVITE") { # rewrite ruri rewriteuri(<PSTN destination>); # signal forking append_hf("Redirection: count=5\r\n"); append_branch(); revert_uri(); t_on_failure("1"); if (!t_relay()){ xlog("acc_info", " ERROR"); sl_reply_error(); } } else if (method=="ACK" || method=="BYE" || method=="CANCEL") { # default message handler } else { # forbidden message handler } } #--------------------------------------------------- # Failure route relay #--------------------------------------------------- route[1] { xlog("acc_info", " Failure route relay"); # try removing it before t_relay if(is_present_hf("Redirection")){ xlog("acc_info", " Remove before t_relay"); remove_hf("Redirection"); } if (!t_relay()){ xlog("acc_info", " ERROR"); sl_reply_error(); } } #--------------------------------------------------- # Failure route handling #--------------------------------------------------- failure_route[1] { xlog("acc_info", " failure route handler"); if(t_check_status("408")) { t_on_branch("1"); rewriteuri(<PSTN destination>); # try removing it before append branch if(is_present_hf("Redirection")){ xlog("acc_info", " Remove before append branch"); remove_hf("Redirection"); } append_branch(); # try removing it after append branch if(is_present_hf("Redirection")){ xlog("acc_info", " Remove after append branch"); remove_hf("Redirection"); } route(1); } }

2 2

[OpenSER-Users] append_hf() and failure_route issue
by Alex Hermann 11 Sep '07

11 Sep '07

Hello all, I'm having some trouble with failure routes and custom SIP headers. In FAILURE_ROUTE I set the ruri to a new destination. This destination needs a custom SIP header. When I add a SIP header with append_hf() (from within the failure_route), this header is correctly sent to the first IP of the destination on t_relay(). However, when this destination fails with 503 or timeout, the built-in DNS based failover doesn't add the custom SIP header to the new requests for subsequent IP's. When the SIP header is added from REQUEST_ROUTE the header is sent to all destinations by the DNS based failover mechanism. How do I get the DNS based failover to send my SIP headers all the time? (The same problem is present with uac_auth()) -- Greetings, Alex Hermann

1 0

← Newer
1
...
16
17
18
19
20
21
22
...
25
Older →

Jump to page:

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