sr-users May 2008

sr-users@lists.kamailio.org

121 participants
203 discussions

Re: [OpenSER-Users] srv load-balancing
by Stanisław Pitucha 05 Jun '08

05 Jun '08

----- "Sajith T S" <sajith(a)gmail.com> wrote: > stanis(a)zimbra-1.gradwell.net wrote: > > > and got 6 calls on asterisk-2 and none on asterisk-1. If I change > > the order, all calls go to the first host on the list. Shouldn't > > openser do load-balancing in this scenario? I don't use any options > > in t_relay(). > > You should use openser dispatcher module for this. Yes... I've just noticed in http://www.openser.org/pipermail/users/2007-October/013660.html that openser basically decided to go against SRV RFC and ignores weights. (RFC says that clients should sort and select from list of servers, not servers as B.A.I. suggested if I understood that correctly) Anyways - about dispatcher: I couldn't find any description about it's behavior with call transfers / taking over. I understand that while I'm using callid-based hash there will be no problems with REFER, because call-id stays the same and each leg will go to the same server. But what about INVITE + Replaces: ? I don't really see a way for it to work just with hashing. Has anyone tested this / has solution? PS. sorry Sajith, I replied to you before by mistake Thanks, Stan

3 2

[Serusers] SER 0.10.x AVP syntax documentation
by Steven C. Blair 04 Jun '08

04 Jun '08

I'm trying to convert my SER 0.9.x config file to a 0.10.x file. I need some help converting AVPs. I use to use rules such as " if (avp_db_load("$ruri/username", "s:callfwdall"))..." however this now generates a syntax error. Is there a how-to which describes how to convert these types of statements to the new format? Thanks,steve Senior Network Engineer, Information Systems and Computing Networking and Telecommunications , Suite 221A /6228 University of Pennsylvania Voice:215-573-8396 FAX:215-898-9348

2 1

Re: [OpenSER-Users] compilation on solaris 10
by Bogdan-Andrei Iancu 04 Jun '08

04 Jun '08

Hi Eric, To be honest, no, I haven;t, because I do not have access to such a machine. Could you post the errors you get now? Regards, Bogdan wliangy(a)gmail.com wrote: > Thanks! > But there is still problem. > May I ask whether you have compiled successfully on Solaris 8 or 10? > > 2008/5/26 Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>: > >> Hi Eric, >> >> use "gmake" and not "make" on Solaris. >> >> Regards, >> Bogdan >> >> wliangy(a)gmail.com wrote: >> >>> Hi experts, >>> I am start user of openser and need use openser to support sctp. >>> now I have download the source codes of openser-1.3.1-tls. >>> then I compiled it, there have many errors that need your supports. >>> >>> e.g. >>> openser-1.3.1-tls> make all >>> Makefile.defs:717: *** missing separator. Stop. >>> >>> then I commented Makefile.defs line717 and 718. >>> # $(warning Old gcc detected ($(CC_SHORTVER)), use >>> gcc >= 3.1 \ >>> # for better results) >>> >>> Errors were still there. >>> >>> openser-1.3.1-tls> make all >>> Makefile:402: warning: overriding commands for target >>> `/opt/CiscoMGC$(DESTDIR)' >>> Makefile:393: warning: ignoring old commands for target >>> `/opt/CiscoMGC$(DESTDIR)' >>> yacc -d -b cfg cfg.y >>> "cfg.y", line 391: warning: redeclaration of precedence of SLASH. >>> >>> conflicts: 1 shift/reduce >>> flex cfg.lex >>> statistics.c:58: warning: #warning STATISTICS: Architecture with no >>> support for atomic operations. Using Locks!! >>> Makefile:402: warning: overriding commands for target >>> `/opt/CiscoMGC$(DESTDIR)' >>> Makefile:393: warning: ignoring old commands for target >>> `/opt/CiscoMGC$(DESTDIR)' >>> Compiling action.c >>> gcc -g -O9 -funroll-loops -Wall -mv8 -DNAME='"openser"' >>> -DVERSION='"1.3.1-notls"' -DARCH='"sparc64"' -DOS='"solaris"' >>> -DCOMPILER='"gcc 2.91.66"' -D__CPU_sparc64 -D__OS_solaris -D__SMP_no >>> -DCFG_DIR='"$(DESTDIR)/etc/openser/"' -DPKG_MALLOC -DSHM_MEM >>> -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE >>> -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC >>> -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 >>> -DHAVE_GETIPNODEBYNAME -DHAVE_SYS_SOCKIO_H -DHAVE_SCHED_YIELD >>> -DHAVE_ALLOCA_H -DUSE_SIGACTION -D_POSIX_PTHREAD_SEMANTICS >>> -DHAVE_DEVPOLL -DHAVE_SELECT -c action.c -o action.o >>> parser/msg_parser.h: In function `char_msg_val': >>> In file included from action.h:27, >>> from action.c:44: >>> parser/msg_parser.h:300: parse error before `)' >>> forward.h: In function `msg_send': >>> In file included from action.c:49: >>> forward.h:95: parse error before `)' >>> forward.h:103: parse error before `)' >>> forward.h:107: parse error before `)' >>> mem/../lock_alloc.h: In function `lock_set_alloc': >>> In file included from mem/../locking.h:66, >>> from mem/../statistics.h:115, >>> from mem/shm_mem.h:33, >>> from ut.h:52, >>> from action.c:54: >>> mem/../lock_alloc.h:68: parse error before `)' >>> ut.h: In function `int2bstr': >>> In file included from action.c:54: >>> ut.h:172: parse error before `)' >>> ut.h: In function `un_escape': >>> ut.h:365: parse error before `)' >>> ut.h: In function `shm_str_dup': >>> ut.h:498: parse error before `)' >>> ut.h: In function `pkg_str_dup': >>> ut.h:515: parse error before `)' >>> ut.h: In function `str_strcmp': >>> ut.h:532: parse error before `)' >>> ut.h:535: parse error before `int' >>> ut.h:539: `minlen' undeclared (first use in this function) >>> ut.h:539: (Each undeclared identifier is reported only once >>> ut.h:539: for each function it appears in.) >>> ut.h:547: `alen' undeclared (first use in this function) >>> ut.h:547: `blen' undeclared (first use in this function) >>> ut.h: In function `str_strcasecmp': >>> ut.h:563: parse error before `)' >>> ut.h:566: parse error before `int' >>> ut.h:570: `minlen' undeclared (first use in this function) >>> ut.h:578: `alen' undeclared (first use in this function) >>> ut.h:578: `blen' undeclared (first use in this function) >>> action.c: In function `run_action_list': >>> action.c:140: parse error before `)' >>> action.c: In function `do_assign': >>> action.c:193: parse error before `)' >>> action.c:202: parse error before `)' >>> action.c:222: parse error before `)' >>> action.c:228: parse error before `)' >>> action.c: In function `do_action': >>> action.c:302: parse error before `)' >>> action.c:309: parse error before `)' >>> action.c:335: parse error before `)' >>> action.c:498: parse error before `)' >>> action.c:524: parse error before `)' >>> action.c:682: parse error before `)' >>> action.c:710: parse error before `)' >>> action.c:723: parse error before `)' >>> action.c:757: parse error before `)' >>> action.c:763: parse error before `)' >>> action.c:807: parse error before `)' >>> action.c:819: parse error before `)' >>> action.c:870: parse error before `)' >>> action.c:896: parse error before `)' >>> action.c:904: parse error before `)' >>> action.c:930: parse error before `)' >>> action.c:939: parse error before `)' >>> action.c:945: parse error before `)' >>> action.c:966: parse error before `)' >>> make: *** [action.o] Error 1 >>> >>> Your any help is much appreciated! >>> >>> BR, >>> Eric >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)lists.openser.org >>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >> > >

4 5

[OpenSER-Users] Problem using path module
by Thomas Mangin 03 Jun '08

03 Jun '08

Hello, I am trying to configure a number of openser servers. I have the following testbed: Phone1 + Proxy - Registrar - out proxy Phone2/ The Proxy acts as outbound proxy for customers and uses ienum to route messages to the right registrar (using user@domain), the registrar then figures out where the destination is and sends the packet out to ENUM/PSTN or in my case back to the same proxy. The proxy is running nathelper (and redirects rtp to an rtp proxy) and performs route-recording. The proxy configuration has: modparam("path", "use_received", 0) and the registrar configuration contains: modparam("registrar", "use_path", 1) modparam("registrar", "path_mode", 0) modparam("registrar", "path_use_received", 1) When registering all is fine and well and the packet flows like: Phone<X> -> Proxy -> Registrar (storing in DB) -> Proxy -> Phone<X> and the DB contains in path: <sip:ProxyIP;lr;received=sip:PhoneIP:PhonePort> However, when performing an invite the ACK packet (INVITE/OK/ACK) can not be routed properly as it is not part of the transaction, which causes the call to be cancelled after a few seconds (as it should be given the constance). The ACK packet starts as URI: <sip:user@<Registrar IP>:5060;rinstance=xxxxxx> Contact: <sip:user@PhoneIP:PhonePort> with the IP and Port correctly translated from the internal to the firewall external. It then travels like this: Phone1 -> Proxy -> Registrar > Proxy <stop here> When leaving Registrar the ACK URI has been changed to the one stored in the DB path field ie: <sip:ProxyIP;lr;ftag=yyyyyy> at that point the Proxy is not able to figure out where to forward the packet even if the Contact field of the packet is still correctly set to the IP:Port of the phone to be reached. I was wondering if I am missing some understanding of how RFC3327 is working. I can see a few possible solutions: - generate a first Path header with the Phone information on the proxy before the current one. - try to catch those 'out of transaction ACK' and set the URI to the contact But before doing anything I would appreciate if someone could let me know if I am attempting something idiotic from a design point of view and tell me why what I expected to 'just work' does not behave as expected. Thank you very much your your time and help. Thomas

1 1

[OpenSER-Users] Register Distributed
by Marcio 02 Jun '08

02 Jun '08

Hi, Someone could have tips on how to register in local domain a UAc mobility of another domain (federation) using the OpenSER's config....when one of the INVITE's UAc have to be verified as valid in the home domain and the answer would be allowed its domain registration in place, with a pointer/indicator in the home domain...where he was as that moment?? UAs(local) (accept register after validation on UAs(home) \ \ (Invite/register) \ UAc (mobility)-- -- -- -- -- UAs(home Thx for any help... Marcio

2 2

[OpenSER-Users] Please help with "auth:pre_auth: credentials with given realm not found" error
by mark morreny 31 May '08

31 May '08

Hi, I have found a few posts on this error from Google but none of the solutions works. I am able to use radius_proxy_authorize for REGISTER request without problem. But when I use radius_proxy_authorize for INVITE, Opensers can't authroize it. I have tried: radius_proxy_authorize("192.168.1.104")) proxy_authorize("192.168.1.104","subscriber") radius_proxy_authorize("")) proxy_authorize("","subscriber") I have been stuck with this for days already and I truely hope someone can tell me what could be wrong with my setup. I am pretty much in a stage of desperation right now. Thanks in advance for all your help. Here are the relevant lines in openser.cfg: #if (!radius_proxy_authorize("192.168.1.104")) { if (!proxy_authorize("192.168.1.104","subscriber")) { www_challenge("192.168.1.104","1"); exit; } Here is the openser debug log, I have highlighted the part that proxy_authorize throws error: Jun 1 05:37:16 [29028] DBG:core:parse_msg: SIP Request: Jun 1 05:37:16 [29028] DBG:core:parse_msg: method: <INVITE> Jun 1 05:37:16 [29028] DBG:core:parse_msg: uri: < sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>> Jun 1 05:37:16 [29028] DBG:core:parse_msg: version: <SIP/2.0> Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=2 Jun 1 05:37:16 [29028] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK-f072f593>; state=16 Jun 1 05:37:16 [29028] DBG:core:parse_via: end of header reached, state=5 Jun 1 05:37:16 [29028] DBG:core:parse_headers: via found, flags=2 Jun 1 05:37:16 [29028] DBG:core:parse_headers: this is the first via Jun 1 05:37:16 [29028] DBG:core:receive_msg: After parse_msg... Jun 1 05:37:16 [29028] DBG:core:receive_msg: preparing to run routing scripts... Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=8 Jun 1 05:37:16 [29028] DBG:core:parse_to: end of header reached, state=10 Jun 1 05:37:16 [29028] DBG:core:parse_to: display={"1006"}, ruri={ sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>} Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: <To> [33]; uri=[ sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>] Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: to body ["1006" < sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>> ] Jun 1 05:37:16 [29028] DBG:core:pv_get_to_attr: no To tag Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=ffffffffffffffff Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: cseq <CSeq>: <101> <INVITE> Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: content_length=393 Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: found end of header Jun 1 05:37:16 [29028] DBG:core:parse_to_param: tag=39a9124ca59076d9o0 Jun 1 05:37:16 [29028] DBG:core:parse_to: end of header reached, state=29 Jun 1 05:37:16 [29028] DBG:core:parse_to: display={"1005"}, ruri={ sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104>} Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=14000 Jun 1 05:37:16 [29028] DBG:core:pv_get_authattr: no [Proxy-]Authorization header Sun Jun 1 05:37:16 2008-192.168.1.101::method <INVITE> r-uri < sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>> to-tag <<null>> 2nd via <<null>> to-header <sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>> from-header <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104>> auth-user <<null>> Jun 1 05:37:16 [29028] DBG:maxfwd:is_maxfwd_present: value = 70 Jun 1 05:37:16 [29028] DBG:core:check_via_address: params 192.168.1.101, 192.168.1.101, 0 Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=80 before fix nated contact Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=80 Jun 1 05:37:16 [29028] DBG:uri:has_totag: no totag Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=78 Jun 1 05:37:16 [29028] DBG:tm:t_lookup_request: start searching: hash=59293, isACK=0 Jun 1 05:37:16 [29028] DBG:tm:matching_3261: RFC3261 transaction matching failed Jun 1 05:37:16 [29028] DBG:tm:t_lookup_request: no transaction found Jun 1 05:37:16 [29028] DBG:domain:is_domain_local: Realm '192.168.1.104' is local Jun 1 05:37:16 [29028] DBG:core:db_free_rows: freeing 1 rows Jun 1 05:37:16 [29028] DBG:core:db_free_rows: row[0]=0x81a1c28 Jun 1 05:37:16 [29028] DBG:core:db_free_rows: 0x81a1c28=pkg_free() RES_ROWS Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=10000 Jun 1 05:37:16 [29028] DBG:auth:pre_auth: credentials with given realm not found Jun 1 05:37:16 [29028] DBG:auth:build_auth_hf: 'WWW-Authenticate: Digest realm="192.168.1.104", nonce="4841c6380fa8573a4e9794b1a0a2df9f3e53cb49", qop="auth" ' Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=ffffffffffffffff Jun 1 05:37:16 [29028] DBG:core:check_via_address: params 192.168.1.101, 192.168.1.101, 0 Jun 1 05:37:16 [29028] DBG:core:destroy_avp_list: destroying list 0xb5bf9be0 Jun 1 05:37:16 [29028] DBG:core:receive_msg: cleaning up Jun 1 05:37:16 [29028] DBG:core:parse_msg: SIP Request: Jun 1 05:37:16 [29028] DBG:core:parse_msg: method: <ACK> Jun 1 05:37:16 [29028] DBG:core:parse_msg: uri: < sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>> Jun 1 05:37:16 [29028] DBG:core:parse_msg: version: <SIP/2.0> Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=2 Jun 1 05:37:16 [29028] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK-f072f593>; state=16 Jun 1 05:37:16 [29028] DBG:core:parse_via: end of header reached, state=5 Jun 1 05:37:16 [29028] DBG:core:parse_headers: via found, flags=2 Jun 1 05:37:16 [29028] DBG:core:parse_headers: this is the first via Jun 1 05:37:16 [29028] DBG:core:receive_msg: After parse_msg... Jun 1 05:37:16 [29028] DBG:core:receive_msg: preparing to run routing scripts... Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=8 Jun 1 05:37:16 [29028] DBG:core:parse_to_param: tag=026ab2c49274b4e0186dd72188f7d50a.939a Jun 1 05:37:16 [29028] DBG:core:parse_to: end of header reached, state=29 Jun 1 05:37:16 [29028] DBG:core:parse_to: display={"1006"}, ruri={ sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>} Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: <To> [75]; uri=[ sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>] Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: to body ["1006" < sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>>] Jun 1 05:37:16 [29028] DBG:sl:sl_filter_ACK: local ACK found -> dropping it! Jun 1 05:37:16 [29028] DBG:core:destroy_avp_list: destroying list (nil) Jun 1 05:37:16 [29028] DBG:core:receive_msg: cleaning up Jun 1 05:37:16 [29028] DBG:core:parse_msg: SIP Request: Jun 1 05:37:16 [29028] DBG:core:parse_msg: method: <INVITE> Jun 1 05:37:16 [29028] DBG:core:parse_msg: uri: < sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>> Jun 1 05:37:16 [29028] DBG:core:parse_msg: version: <SIP/2.0> Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=2 Jun 1 05:37:16 [29028] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK-dc12d56c>; state=16 Jun 1 05:37:16 [29028] DBG:core:parse_via: end of header reached, state=5 Jun 1 05:37:16 [29028] DBG:core:parse_headers: via found, flags=2 Jun 1 05:37:16 [29028] DBG:core:parse_headers: this is the first via Jun 1 05:37:16 [29028] DBG:core:receive_msg: After parse_msg... Jun 1 05:37:16 [29028] DBG:core:receive_msg: preparing to run routing scripts... Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=8 Jun 1 05:37:16 [29028] DBG:core:parse_to: end of header reached, state=10 Jun 1 05:37:16 [29028] DBG:core:parse_to: display={"1006"}, ruri={ sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>} Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: <To> [33]; uri=[ sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>] Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: to body ["1006" < sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>> ] Jun 1 05:37:16 [29028] DBG:core:pv_get_to_attr: no To tag Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=ffffffffffffffff Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: cseq <CSeq>: <102> <INVITE> Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: content_length=393 Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: found end of header Jun 1 05:37:16 [29028] DBG:core:parse_to_param: tag=39a9124ca59076d9o0 Jun 1 05:37:16 [29028] DBG:core:parse_to: end of header reached, state=29 Jun 1 05:37:16 [29028] DBG:core:parse_to: display={"1005"}, ruri={ sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104>} Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=14000 Sun Jun 1 05:37:16 2008-192.168.1.101::method <INVITE> r-uri < sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>> to-tag <<null>> 2nd via <<null>> to-header <sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>> from-header <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104>> auth-user <1005> Jun 1 05:37:16 [29028] DBG:maxfwd:is_maxfwd_present: value = 70 Jun 1 05:37:16 [29028] DBG:core:check_via_address: params 192.168.1.101, 192.168.1.101, 0 Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=80 Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=80 Jun 1 05:37:16 [29028] DBG:uri:has_totag: no totag Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=78 Jun 1 05:37:16 [29028] DBG:tm:t_lookup_request: start searching: hash=59290, isACK=0 Jun 1 05:37:16 [29028] DBG:tm:matching_3261: RFC3261 transaction matching failed Jun 1 05:37:16 [29028] DBG:tm:t_lookup_request: no transaction found Jun 1 05:37:16 [29028] DBG:domain:is_domain_local: Realm '192.168.1.104' is local Jun 1 05:37:16 [29028] DBG:core:db_free_rows: freeing 1 rows Jun 1 05:37:16 [29028] DBG:core:db_free_rows: row[0]=0x81a1c28 Jun 1 05:37:16 [29028] DBG:core:db_free_rows: 0x81a1c28=pkg_free() RES_ROWS Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=10000 Jun 1 05:37:16 [29028] DBG:auth:pre_auth: credentials with given realm not found Jun 1 05:37:16 [29028] DBG:auth:build_auth_hf: 'WWW-Authenticate: Digest realm="192.168.1.104", nonce="4841c6380fa8573a4e9794b1a0a2df9f3e53cb49", qop="auth" ' Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=ffffffffffffffff Jun 1 05:37:16 [29028] DBG:core:check_via_address: params 192.168.1.101, 192.168.1.101, 0 Jun 1 05:37:16 [29028] DBG:core:destroy_avp_list: destroying list 0xb5bf9be0 Jun 1 05:37:16 [29028] DBG:core:receive_msg: cleaning up Jun 1 05:37:16 [29028] DBG:core:parse_msg: SIP Request: Jun 1 05:37:16 [29028] DBG:core:parse_msg: method: <ACK> Jun 1 05:37:16 [29028] DBG:core:parse_msg: uri: < sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>> Jun 1 05:37:16 [29028] DBG:core:parse_msg: version: <SIP/2.0> Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=2 Jun 1 05:37:16 [29028] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK-dc12d56c>; state=16 Jun 1 05:37:16 [29028] DBG:core:parse_via: end of header reached, state=5 Jun 1 05:37:16 [29028] DBG:core:parse_headers: via found, flags=2 Jun 1 05:37:16 [29028] DBG:core:parse_headers: this is the first via Jun 1 05:37:16 [29028] DBG:core:receive_msg: After parse_msg... Jun 1 05:37:16 [29028] DBG:core:receive_msg: preparing to run routing scripts... Jun 1 05:37:16 [29028] DBG:core:parse_headers: flags=8 Jun 1 05:37:16 [29028] DBG:core:parse_to_param: tag=026ab2c49274b4e0186dd72188f7d50a.6388 Jun 1 05:37:16 [29028] DBG:core:parse_to: end of header reached, state=29 Jun 1 05:37:16 [29028] DBG:core:parse_to: display={"1006"}, ruri={ sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>} Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: <To> [75]; uri=[ sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>] Jun 1 05:37:16 [29028] DBG:core:get_hdr_field: to body ["1006" < sip:1006@192.168.1.104 <sip%3A1006(a)192.168.1.104>>] Jun 1 05:37:16 [29028] DBG:sl:sl_filter_ACK: local ACK found -> dropping it! Jun 1 05:37:16 [29028] DBG:core:destroy_avp_list: destroying list (nil) Jun 1 05:37:16 [29028] DBG:core:receive_msg: cleaning up Here is the SIP trace: U 192.168.1.101:5062 -> 192.168.1.104:5060 INVITE sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> SIP/2.0. Via: SIP/2.0/UDP 192.168.1.101:5062;branch=z9hG4bK-d392c9a5. From: "1005" <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=131fa1047c30f2a4o0. To: <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104>>. Call-ID: a3888884-92d13124(a)192.168.1.101. CSeq: 101 INVITE. Max-Forwards: 70. Contact: "1005" <sip:1005@192.168.1.101:5062>. Expires: 240. User-Agent: Sipura/SPA921-4.1.10(b). Content-Length: 395. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Content-Type: application/sdp. . v=0. o=- 36185 36185 IN IP4 192.168.1.101. s=-. c=IN IP4 192.168.1.101. t=0 0. m=audio 16424 RTP/AVP 0 2 4 8 18 96 97 98 101. a=rtpmap:0 PCMU/8000. a=rtpmap:2 G726-32/8000. a=rtpmap:4 G723/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729a/8000. a=rtpmap:96 G726-40/8000. a=rtpmap:97 G726-24/8000. a=rtpmap:98 G726-16/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. U 192.168.1.104:5060 -> 192.168.1.101:5062 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.1.101:5062;branch=z9hG4bK-d392c9a5;rport=5062. From: "1005" <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=131fa1047c30f2a4o0. To: <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=026ab2c49274b4e0186dd72188f7d50a.f608. Call-ID: a3888884-92d13124(a)192.168.1.101. CSeq: 101 INVITE. WWW-Authenticate: Digest realm="192.168.1.104", nonce="4841caae665a98cec71734a5cf84c70d10ac8f63", qop="auth". Server: OpenSER (1.3.2-notls (i386/linux)). Content-Length: 0. . U 192.168.1.101:5062 -> 192.168.1.104:5060 ACK sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> SIP/2.0. Via: SIP/2.0/UDP 192.168.1.101:5062;branch=z9hG4bK-d392c9a5. From: "1005" <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=131fa1047c30f2a4o0. To: <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=026ab2c49274b4e0186dd72188f7d50a.f608. Call-ID: a3888884-92d13124(a)192.168.1.101. CSeq: 101 ACK. Max-Forwards: 70. Contact: "1005" <sip:1005@192.168.1.101:5062>. User-Agent: Sipura/SPA921-4.1.10(b). Content-Length: 0. . U 192.168.1.101:5062 -> 192.168.1.104:5060 INVITE sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> SIP/2.0. Via: SIP/2.0/UDP 192.168.1.101:5062;branch=z9hG4bK-4cf05fb6. From: "1005" <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=131fa1047c30f2a4o0. To: <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104>>. Call-ID: a3888884-92d13124(a)192.168.1.101. CSeq: 102 INVITE. Max-Forwards: 70. Authorization: Digest username="1005",realm="192.168.1.104 ",nonce="4841caae665a98cec71734a5cf84c70d10ac8f63",uri=" sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> ",algorithm=MD5,response="e39bd9dc46a72ea191fca87e98cf9136",qop=auth,nc=00000001,cnonce="9d027a79". Contact: "1005" <sip:1005@192.168.1.101:5062>. Expires: 240. User-Agent: Sipura/SPA921-4.1.10(b). Content-Length: 395. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Content-Type: application/sdp. . v=0. o=- 36185 36185 IN IP4 192.168.1.101. s=-. c=IN IP4 192.168.1.101. t=0 0. m=audio 16424 RTP/AVP 0 2 4 8 18 96 97 98 101. a=rtpmap:0 PCMU/8000. a=rtpmap:2 G726-32/8000. a=rtpmap:4 G723/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729a/8000. a=rtpmap:96 G726-40/8000. a=rtpmap:97 G726-24/8000. a=rtpmap:98 G726-16/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. U 192.168.1.104:5060 -> 192.168.1.101:5062 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.1.101:5062;branch=z9hG4bK-4cf05fb6;rport=5062. From: "1005" <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=131fa1047c30f2a4o0. To: <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=026ab2c49274b4e0186dd72188f7d50a.218e. Call-ID: a3888884-92d13124(a)192.168.1.101. CSeq: 102 INVITE. WWW-Authenticate: Digest realm="192.168.1.104", nonce="4841caae665a98cec71734a5cf84c70d10ac8f63", qop="auth". Server: OpenSER (1.3.2-notls (i386/linux)). Content-Length: 0. . U 192.168.1.101:5062 -> 192.168.1.104:5060 ACK sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> SIP/2.0. Via: SIP/2.0/UDP 192.168.1.101:5062;branch=z9hG4bK-4cf05fb6. From: "1005" <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=131fa1047c30f2a4o0. To: <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=026ab2c49274b4e0186dd72188f7d50a.218e. Call-ID: a3888884-92d13124(a)192.168.1.101. CSeq: 102 ACK. Max-Forwards: 70. Authorization: Digest username="1005",realm="192.168.1.104 ",nonce="4841caae665a98cec71734a5cf84c70d10ac8f63",uri=" sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> ",algorithm=MD5,response="dc66b568ed8ec48f0f405aa063156eaa",qop=auth,nc=00000001,cnonce="9d027a79". Contact: "1005" <sip:1005@192.168.1.101:5062>. User-Agent: Sipura/SPA921-4.1.10(b). Content-Length: 0. . U 192.168.1.101:5062 -> 192.168.1.104:5060 INVITE sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> SIP/2.0. Via: SIP/2.0/UDP 192.168.1.101:5062;branch=z9hG4bK-e2c260be. From: "1005" <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=131fa1047c30f2a4o0. To: <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104>>. Call-ID: a3888884-92d13124(a)192.168.1.101. CSeq: 103 INVITE. Max-Forwards: 70. Authorization: Digest username="1005",realm="192.168.1.104 ",nonce="4841caae665a98cec71734a5cf84c70d10ac8f63",uri=" sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> ",algorithm=MD5,response="8d2b52278a72326a57361ec1ca2601c3",qop=auth,nc=00000001,cnonce="f4b6f3a0". Contact: "1005" <sip:1005@192.168.1.101:5062>. Expires: 240. User-Agent: Sipura/SPA921-4.1.10(b). Content-Length: 395. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Content-Type: application/sdp. . v=0. o=- 36185 36185 IN IP4 192.168.1.101. s=-. c=IN IP4 192.168.1.101. t=0 0. m=audio 16424 RTP/AVP 0 2 4 8 18 96 97 98 101. a=rtpmap:0 PCMU/8000. a=rtpmap:2 G726-32/8000. a=rtpmap:4 G723/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729a/8000. a=rtpmap:96 G726-40/8000. a=rtpmap:97 G726-24/8000. a=rtpmap:98 G726-16/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. U 192.168.1.104:5060 -> 192.168.1.101:5062 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.1.101:5062;branch=z9hG4bK-e2c260be;rport=5062. From: "1005" <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=131fa1047c30f2a4o0. To: <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=026ab2c49274b4e0186dd72188f7d50a.8d8a. Call-ID: a3888884-92d13124(a)192.168.1.101. CSeq: 103 INVITE. WWW-Authenticate: Digest realm="192.168.1.104", nonce="4841caae665a98cec71734a5cf84c70d10ac8f63", qop="auth". Server: OpenSER (1.3.2-notls (i386/linux)). Content-Length: 0. . U 192.168.1.101:5062 -> 192.168.1.104:5060 ACK sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> SIP/2.0. Via: SIP/2.0/UDP 192.168.1.101:5062;branch=z9hG4bK-e2c260be. From: "1005" <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=131fa1047c30f2a4o0. To: <sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> >;tag=026ab2c49274b4e0186dd72188f7d50a.8d8a. Call-ID: a3888884-92d13124(a)192.168.1.101. CSeq: 103 ACK. Max-Forwards: 70. Authorization: Digest username="1005",realm="192.168.1.104 ",nonce="4841caae665a98cec71734a5cf84c70d10ac8f63",uri=" sip:1005@192.168.1.104 <sip%3A1005(a)192.168.1.104> ",algorithm=MD5,response="8ebde837f7c7c49f721d9f2c44b3797d",qop=auth,nc=00000001,cnonce="f4b6f3a0". Contact: "1005" <sip:1005@192.168.1.101:5062>. User-Agent: Sipura/SPA921-4.1.10(b). Content-Length: 0.

1 0

[Serusers] (no subject)
by Bin Zhang 31 May '08

31 May '08

-- Bin Zhang

1 0

[OpenSER-Users] Hints about to capture codes negative www_authorize??
by Marcio 30 May '08

30 May '08

Hi, Who would have tips on how to capture the return codes negative of the function "www_authorize" ??? I read somewhere that said to use $retval........but ...How can I to use it ("$retval") ?? -1 - Non existent user; -2 - invalid passwd; -3 - stale nonce; -4 - no credentials; -5 - error; Any help will be greatly appreciated. thx, Marcio

3 5

[OpenSER-Users] Fwd: Re: Installing perl module
by Henning Westerholt 30 May '08

30 May '08

---------- Forward message ---------- Subject: Re: [OpenSER-Users] Installing perl module Date: Freitag, 30. Mai 2008 From: "Yazid Hadj Said" <yazid.hadjsaid(a)gmail.com> Tp: "Henning Westerholt" <henning.westerholt(a)1und1.de> Hi Henning, I think that the problem is in openser ebuild, so I do this modifications: # diff openser-1.3.1.ebuild openser-1.3.1.ebuild.old 7c7 < IUSE="ipv6 mysql radius postgres jabber ssl odbc perl perlvdb" --- 58,63d57 < use perl && < modules="${modules} perl" < < use perlvdb && < modules="${modules} perlvdb" < --------------------------------------- Hi Yazid, please always CC at the list, so that others can read the resolution too. Great that it works now for you. I'm not sure if the ebuild that is included in the openser distribution is also used in gentoo. Perhaps you can file a bug against the gentoo package (on gentoo.org), and attach your patch, so that the maintainer could fix this? Cheers, Henning

2 1

[OpenSER-Users] Installing perl module
by Yazid Hadj Said 30 May '08

30 May '08

Hi, I use 1.3.1 openser version, and i don't find perl module (I don't know Why). My question is if I can add perl module without recompiling openser. (I use Gentoo distribution) Regards Yazid

2 1

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