sr-users January 2007

sr-users@lists.kamailio.org

151 participants
232 discussions

by karim basraoui

Hi, I am using an architecture with Ser and Asterisk. When Ser forwards the calls to asterisk, everything is all right. the caller has a "ringing" message and the callee rings. when the callee picks up, the caller has a "connecting" message but the callee hungs up suddenly. my asterisk shows the message: -- Got SIP Response 503 "server error" back from Ser_ip -- how can i tell to asterisk to setup the call ? thank you ! -- BASRAOUI Karim

17 years, 3 months

[Serusers] SER forwarding to Asterisk

by karim basraoui

Hi, The topic may have been already discussed, but still there are some problems. I have an architecture like this : UA1 ->SER -> ASTERISK -> UA2 when UA1 sends an INVITE to UA2, SER forwards the call to ASTERISK, i can hear UA2 ringing. however, when UA2 answers, i can see "connected" on UA1 but UA2 hungs up by itself, as if ASTERISK cancels the call. is there any solution to oblige ASTERISK to forward the "200 OK" to SER? thanks in advance -- BASRAOUI Karim

17 years, 3 months

[Users] authentication protocol

by Artur Hayne

Hi, Its possible the openser change the authentication protocol of the digest for otherone? Thanks Artur. __________________________________________________ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/

17 years, 3 months

[Serusers] Re: [OpenIMSCore-Users] Getting 513 - Message too big for REGISTER message

by Dragos Vingarzan

Strange, this looks like a SER bug... Just comment these line and if you want to pursue it further, please report it on the serdev(a)iptel.org mailing lists. It seems to be only relevant to Solaris though. -Dragos Sudhakar Patil wrote: > Hello, > I am using FOKUS OpenIMSCore modules and configuration > that are built around SER. > > I am running the software on Solaris 8 OS with Sparc > v9 architecture and 64 bit compilation. > > I am using xten client. It sends REGISTER message but > gets 513: Message too long in the response. The actual > message size is 546 bytes. I have placed some DBG > commands in SER receive.c and action.c. Everywhere the > message size seems to be correct and is 546 bytes. > > The .cfg file of sip2ims module has the following code > snippet: > > if (msg:len >= max_len ) { > sl_send_reply("513", "Message too big"); > exit; > }; > > I tracked the code eventually to route.c, comp_num > function where the comparison is made between msg:len > and max_len. However, when I print left and right > numbers, the right number is always 0 and hence the > expression is always TRUE and I get 513 always. > (Please see 1(22318) In comp_num. left 546, right 0 > debug output below) > > Below is the output of sip2ims module. > > Any help in fixing this problem is greatly > appreciated. > > > 1(22318) qm_malloc(100224ce8, 1392) called from > receive.c: receive_msg(92) > 1(22318) qm_malloc(100224ce8, 1392) returns address > 100265d38 frag. 100265d08 (size=1392) on 1 -th hit > 1(22318) SIP Request: > 1(22318) method: <REGISTER> > 1(22318) uri: <sip:open-ims.test> > 1(22318) version: <SIP/2.0> > 1(22318) parse_headers: flags=2 > 1(22318) qm_malloc(100224ce8, 64) called from > parser/msg_parser.c: parse_headers(297) > 1(22318) qm_malloc(100224ce8, 64) returns address > 1002657d0 frag. 1002657a0 (size=64) on 1 -th hit > 1(22318) qm_malloc(100224ce8, 232) called from > parser/msg_parser.c: get_hdr_field(111) > 1(22318) qm_malloc(100224ce8, 232) returns address > 100265870 frag. 100265840 (size=232) on 1 -th hit > 1(22318) qm_malloc(100224ce8, 64) called from > parser/parse_via.c: parse_via(2142) > 1(22318) qm_malloc(100224ce8, 64) returns address > 1002659b8 frag. 100265988 (size=64) on 1 -th hit > 1(22318) Found param type 232, <branch> = > <z9hG4bK-d87543-27653f391711d351-1--d87543->; state=6 > 1(22318) qm_malloc(100224ce8, 64) called from > parser/parse_via.c: parse_via(2142) > 1(22318) qm_malloc(100224ce8, 64) returns address > 100265a58 frag. 100265a28 (size=64) on 1 -th hit > 1(22318) Found param type 235, <rport> = <n/a>; > state=17 > 1(22318) end of header reached, state=5 > 1(22318) parse_headers: Via found, flags=2 > 1(22318) parse_headers: this is the first via > 1(22318) After parse_msg... > 1(22318) preparing to run routing scripts... > 1(22318) Message length 546 > 1(22318) completed exec_pre_cb > 1(22318) Before run_actions: message length 546 > 1(22318) Message length in run_actions546 > 1(22318) In ROUTE_T 1 546 > 1(22318) Message length in run_actions546 > 1(22318) Message length in run_actions546 > 1(22318) parse_headers: flags=100 > 1(22318) qm_malloc(100224ce8, 64) called from > parser/msg_parser.c: parse_headers(297) > 1(22318) qm_malloc(100224ce8, 64) returns address > 100265af8 frag. 100265ac8 (size=64) on 1 -th hit > 1(22318) DEBUG:maxfwd:is_maxfwd_present: value = 70 > 1(22318) DBG:maxfwd:process_maxfwd_header: value 70 > decreased to 16 > 1(22318) priting e structure 0 > -------------------------------------------- > 1(22318) In comp_num. left 546, right 0 > -------------------------------------------- > 1(22318) Message length in run_actions546 > 1(22318) qm_malloc(100224ce8, 21) called from ut.c: > as_asciiz(135) > 1(22318) qm_malloc(100224ce8, 24) returns address > 100265b98 frag. 100265b68 (size=24) on 1 -th hit > 1(22318) parse_headers: flags=8 > 1(22318) qm_malloc(100224ce8, 64) called from > parser/msg_parser.c: parse_headers(297) > 1(22318) qm_malloc(100224ce8, 64) returns address > 100265c10 frag. 100265be0 (size=200) on 1 -th hit > 1(22318) qm_malloc(100224ce8, 64) called from > parser/msg_parser.c: parse_headers(297) > 1(22318) qm_malloc(100224ce8, 64) returns address > 100266308 frag. 1002662d8 (size=64) on 1 -th hit > 1(22318) qm_malloc(100224ce8, 88) called from > parser/msg_parser.c: get_hdr_field(151) > 1(22318) qm_malloc(100224ce8, 88) returns address > 1002663a8 frag. 100266378 (size=88) on 1 -th hit > 1(22318) end of header reached, state=9 > 1(22318) DEBUG: get_hdr_field: <To> [34]; > uri=[sip:alice@open-ims.test] > 1(22318) DEBUG: to body > ["alice"<sip:alice@open-ims.test> > ] > 1(22318) parse_headers: flags=ffffffffffffffff > 1(22318) qm_malloc(100224ce8, 64) called from > parser/msg_parser.c: parse_headers(297) > 1(22318) qm_malloc(100224ce8, 64) returns address > 100266460 frag. 100266430 (size=64) on 1 -th hit > 1(22318) qm_malloc(100224ce8, 64) called from > parser/msg_parser.c: parse_headers(297) > 1(22318) qm_malloc(100224ce8, 64) returns address > 100266500 frag. 1002664d0 (size=64) on 1 -th hit > 1(22318) qm_malloc(100224ce8, 64) called from > parser/msg_parser.c: parse_headers(297) > 1(22318) qm_malloc(100224ce8, 64) returns address > 1002665a0 frag. 100266570 (size=64) on 1 -th hit > 1(22318) qm_malloc(100224ce8, 40) called from > parser/msg_parser.c: get_hdr_field(130) > 1(22318) qm_malloc(100224ce8, 40) returns address > 100266640 frag. 100266610 (size=40) on 1 -th hit > 1(22318) get_hdr_field: cseq <CSeq>: <1> <REGISTER> > 1(22318) qm_malloc(100224ce8, 64) called from > parser/msg_parser.c: parse_headers(297) > 1(22318) qm_malloc(100224ce8, 64) returns address > 1002666c8 frag. 100266698 (size=64) on 1 -th hit > 1(22318) qm_malloc(100224ce8, 64) called from > parser/msg_parser.c: parse_headers(297) > 1(22318) qm_malloc(100224ce8, 64) returns address > 100266768 frag. 100266738 (size=64) on 1 -th hit > 1(22318) qm_malloc(100224ce8, 64) called from > parser/msg_parser.c: parse_headers(297) > 1(22318) qm_malloc(100224ce8, 64) returns address > 100266808 frag. 1002667d8 (size=64) on 1 -th hit > 1(22318) qm_malloc(100224ce8, 64) called from > parser/msg_parser.c: parse_headers(297) > 1(22318) qm_malloc(100224ce8, 64) returns address > 1002668a8 frag. 100266878 (size=64) on 1 -th hit > 1(22318) DEBUG: get_hdr_body : content_length=0 > 1(22318) qm_malloc(100224ce8, 64) called from > parser/msg_parser.c: parse_headers(297) > 1(22318) qm_malloc(100224ce8, 64) returns address > 100266948 frag. 100266918 (size=64) on 1 -th hit > 1(22318) found end of header > 1(22318) qm_free(100224ce8, 100266948), called from > parser/msg_parser.c: parse_headers(313) > 1(22318) qm_free: freeing frag. 100266918 alloc'ed > from parser/msg_parser.c: parse_headers(297) > 1(22318) check_via_address(192.168.120.1, > 192.168.120.1, 0) > 1(22318) qm_malloc(100224ce8, 13) called from > msg_translator.c: rport_builder(353) > 1(22318) qm_malloc(100224ce8, 16) returns address > 100266948 frag. 100266918 (size=64) on 1 -th hit > 1(22318) qm_malloc(100224ce8, 609) called from > msg_translator.c: build_res_buf_from_sip_req(1824) > 1(22318) qm_malloc(100224ce8, 616) returns address > 1002669e8 frag. 1002669b8 (size=616) on 1 -th hit > 1(22318) qm_free(100224ce8, 100266948), called from > msg_translator.c: build_res_buf_from_sip_req(1984) > 1(22318) qm_free: freeing frag. 100266918 alloc'ed > from msg_translator.c: rport_builder(353) > 1(22318) qm_free(100224ce8, 1002669e8), called from > sl_funcs.c: sl_send_reply(176) > 1(22318) qm_free: freeing frag. 1002669b8 alloc'ed > from msg_translator.c: > build_res_buf_from_sip_req(1824) > 1(22318) qm_free(100224ce8, 100265b98), called from > sl.c: w_sl_send_reply(178) > 1(22318) qm_free: freeing frag. 100265b68 alloc'ed > from ut.c: as_asciiz(135) > 1(22318) After run_actions > 1(22318) DEBUG:destroy_avp_list: destroying list 0 > 1(22318) DEBUG:destroy_avp_list: destroying list 0 > 1(22318) DEBUG:destroy_avp_list: destroying list 0 > 1(22318) DEBUG:destroy_avp_list: destroying list 0 > 1(22318) DEBUG:destroy_avp_list: destroying list 0 > 1(22318) DEBUG:destroy_avp_list: destroying list 0 > 1(22318) receive_msg: cleaning up > 1(22318) qm_free(100224ce8, 1002659b8), called from > parser/parse_via.c: free_via_param_list(2361) > 1(22318) qm_free: freeing frag. 100265988 alloc'ed > from parser/parse_via.c: parse_via(2142) > 1(22318) qm_free(100224ce8, 100265a58), called from > parser/parse_via.c: free_via_param_list(2361) > 1(22318) qm_free: freeing frag. 100265a28 alloc'ed > from parser/parse_via.c: parse_via(2142) > 1(22318) qm_free(100224ce8, 100265870), called from > parser/parse_via.c: free_via_list(2373) > 1(22318) qm_free: freeing frag. 100265840 alloc'ed > from parser/msg_parser.c: get_hdr_field(111) > 1(22318) qm_free(100224ce8, 1002657d0), called from > parser/hf.c: free_hdr_field_lst(209) > 1(22318) qm_free: freeing frag. 1002657a0 alloc'ed > from parser/msg_parser.c: parse_headers(297) > 1(22318) qm_free(100224ce8, 100265af8), called from > parser/hf.c: free_hdr_field_lst(209) > 1(22318) qm_free: freeing frag. 100265ac8 alloc'ed > from parser/msg_parser.c: parse_headers(297) > 1(22318) qm_free(100224ce8, 100265c10), called from > parser/hf.c: free_hdr_field_lst(209) > 1(22318) qm_free: freeing frag. 100265be0 alloc'ed > from parser/msg_parser.c: parse_headers(297) > 1(22318) qm_free(100224ce8, 1002663a8), called from > parser/parse_to.c: free_to(784) > 1(22318) qm_free: freeing frag. 100266378 alloc'ed > from parser/msg_parser.c: get_hdr_field(151) > 1(22318) qm_free(100224ce8, 100266308), called from > parser/hf.c: free_hdr_field_lst(209) > 1(22318) qm_free: freeing frag. 1002662d8 alloc'ed > from parser/msg_parser.c: parse_headers(297) > 1(22318) qm_free(100224ce8, 100266460), called from > parser/hf.c: free_hdr_field_lst(209) > 1(22318) qm_free: freeing frag. 100266430 alloc'ed > from parser/msg_parser.c: parse_headers(297) > 1(22318) qm_free(100224ce8, 100266500), called from > parser/hf.c: free_hdr_field_lst(209) > 1(22318) qm_free: freeing frag. 1002664d0 alloc'ed > from parser/msg_parser.c: parse_headers(297) > 1(22318) qm_free(100224ce8, 100266640), called from > parser/parse_cseq.c: free_cseq(102) > 1(22318) qm_free: freeing frag. 100266610 alloc'ed > from parser/msg_parser.c: get_hdr_field(130) > 1(22318) qm_free(100224ce8, 1002665a0), called from > parser/hf.c: free_hdr_field_lst(209) > 1(22318) qm_free: freeing frag. 100266570 alloc'ed > from parser/msg_parser.c: parse_headers(297) > 1(22318) qm_free(100224ce8, 1002666c8), called from > parser/hf.c: free_hdr_field_lst(209) > 1(22318) qm_free: freeing frag. 100266698 alloc'ed > from parser/msg_parser.c: parse_headers(297) > 1(22318) qm_free(100224ce8, 100266768), called from > parser/hf.c: free_hdr_field_lst(209) > 1(22318) qm_free: freeing frag. 100266738 alloc'ed > from parser/msg_parser.c: parse_headers(297) > 1(22318) qm_free(100224ce8, 100266808), called from > parser/hf.c: free_hdr_field_lst(209) > 1(22318) qm_free: freeing frag. 1002667d8 alloc'ed > from parser/msg_parser.c: parse_headers(297) > 1(22318) qm_free(100224ce8, 1002668a8), called from > parser/hf.c: free_hdr_field_lst(209) > 1(22318) qm_free: freeing frag. 100266878 alloc'ed > from parser/msg_parser.c: parse_headers(297) > 1(22318) qm_free(100224ce8, 100265d38), called from > receive.c: receive_msg(239) > 1(22318) qm_free: freeing frag. 100265d08 alloc'ed > from receive.c: receive_msg(92) > > Regards, > Sudhakar. > > > > > > > > ____________________________________________________________________________________ > The fish are biting. > Get more visitors on your site using Yahoo! Search Marketing. > http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php > _______________________________________________ > OpenIMSCore-Users mailing list > OpenIMSCore-Users(a)lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openimscore-users > > -- ----------------------------------------- Dipl. Eng. Dragos Vingarzan FOKUS/NGNI Kaiserin-Augusta-Allee 31 10589 Berlin,Germany Phone +49 (0)30 - 3463 - 7385 Mobile +49 (0)163 - 159 - 5221 eMail vingarzan(a)fokus.fraunhofer.de Web www.fokus.fraunhofer.de We could change the world if God would give us the source code... -----------------------------------------------------------------

17 years, 3 months

[Serusers] Signalig through 2 proxies

by Gustavo Passos Tourinho

Hello there. I'm have some strange problem and was wondering if anyone of you can help me. I have 2 scenarios to call from a IP terminal to a PSTN. Scenario1: Terminal >> Proxy1 (statefull)>> Proxy2 (stateless)>> GW (PSTN) Scenario2: Terminal >> Proxy1 (statefull)>> GW (PSTN) The problem is when I use scenario 1. When the terminal sends BYE request, the GW never response with OK. In the other hand, using scenario 2, BYE request is respond with OK (by the GW). The signaling is perfectly normal. The signaling is the same, except by the via header add by second proxy. Thanks in advanced, Gustavo

17 years, 3 months

[Users] avp_db_load

by Brandon Armstead

Hello everyone, I'm trying to load an avp from the database, now from my understanding I simply use the avp_db_load() function. Now I previously setup my avp_table to be usr_preferences, now I'm doing the following: route[5] { xlog("L_INFO", "time [$Tf] method <$rm> r-uri <$ru> 2nd via <$hdr(via[1])>\n"); avp_db_load("$rU/username", "$avp(s:e911)"); xlog("L_INFO", "CURRENT AVP VALUE: $avp(s:e911)"); if(is_avp_set("$avp(s:e911)")) { xlog("L_INFO", "CURRENT \$ru: $ru"); avp_pushto("$ru", "$avp(s:e911)"); xlog("L_INFO", "AFTER \$ru: $ru"); } route(1); } For route 5, and I have a AVP row for 'e911' in the database, with the username, domain, and the attribute set, the attribute ofcourse being e911, type 0, and a value set. However, I keep getting NULL back for the AVP I'm trying to pull, does anyone care to explain what I'm doing wrong? Thanks. -- Brandon Armstead

17 years, 3 months

[Serusers] password length & ha1 calculation

by chiahuey

Hi there, If using plain text password and need to calculate ha1 on the fly, is there any requirement as in there is a minimum length for the password? I am using ser-0.9.6, and facing a strange issue here, if password length < 8, will have inconsistency in successful registration or invite. Always get (401 unauthorized or 407 proxy authentication required). if password length >= 8, will be consistently successful. As we are planning to port the users from another platform, can't change the password for all users. Anyone have any clue in the password length issue? Thanks in advance. Regards, Chia

17 years, 3 months

[Serusers] non-symmetric rtp with rtpproxy??

by Cesc

Hi, I know this probably is a useless question, as rtpproxy says it is a symmetric proxy ... but i have to ask, for peace of mind :) In my setup, i have on one side a symmetric rtp phone (A) ... connected to a ser proxy + rtpproxy ... and on the other side, a non-symmetric phone (B). This is all on a lan, so no firewalls and stuff ... but I MUST use the rtpproxy and I MUST use this non-symmetric phone (more like a gateway, actually). A ------ SER+rtpproxy ------ B (nonsym) So, the funny thing happens that i end up reciving audio from B to A ... and then I hear A's own audio after being bounced by B (funny, huh?). The bouncing is due to rtpproxy changing the rtp port where he sends to B ... he starts with the one announced on SDP ... then, after the first RTP received from B, he switches to this new port ... mmmm I guess this is a lost cause ... but maybe someone has a brilliant idea?? :D (like a hack in rtpproxy which suddenly turns it into non-symmetrical-rtp-supported-endpoint proxy? :D ) Regards, Cesc

17 years, 3 months

[Users] List of Functions

by Brandon Armstead

Hello everyone, I'm wondering if you guys have a list of functions available, core, module, etc, but one compiled list of functions, such as I'm having a hard time finding what module rewritehostport() belongs to, or is it a core function? Like is there an easier way to overview the functions available, whether it be core, or supplied via a module? Thanks, any input appreciated! -- Brandon Armstead

17 years, 3 months

RE: [Users] openser, spa9000, etc.

by juliano Duque

Scott, By default You cannot reach the extensions registered to SPA9000 from the extensions registered at Openser. You will only reach the SPA9000 line registered at Openser. You can reach the other extensions registered at SPA 9000 if the SPA9000 line registered at Openser forward the call to the other extensions or if you set the extensions on SPA9000 to receive calls without authentication but for that to work you need to create aliases for that extensions on Openser pointing it to SPA9000 Regards, Juliano Duque

17 years, 3 months

← Newer
1
2
3
4
5
6
7
8
9
...
24
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 January 2007