sr-users October 2007

sr-users@lists.kamailio.org

130 participants
286 discussions

Re: [OpenSER-Users] transaction flags not visible in CANCEL
by Papadopoulos Georgios 30 Oct '07

30 Oct '07

Hi Bogdan, Flag inheritance by the replies works. I did not know that it was not supposed to work for the CANCEL. It is good to know because I was starting to loose my mind... Maybe a note somewhere in the project's site would be useful. It is very strange behaviour because t_check_trans() returns true which means that the CANCEL belongs to an existing transaction, but the flags are not the same as the original. Last question: What about Re-INVITEs? The flags are not working there either? If this is true, then the only way to save some information about the transaction is to add it as a parameter in the contact? Or is there some other way? Thank you. Best regards George > -----Original Message----- > From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] > Sent: Tuesday, October 30, 2007 6:07 AM > To: Papadopoulos Georgios > Cc: users(a)lists.openser.org > Subject: Re: [OpenSER-Users] transaction flags not visible in CANCEL > > Hi George, > > There are two cases you are referring at: > > 1) flags inheritance by the replies (set flag in INVITE and see it in > replies) - is this working? > > 2) flags inheritance by the CANCEL (set flag in INVITE and > see it in CANCEL req/reply) - this is know not to work as so > far the CANCEL was a different transaction then the INVITE, > but starting with 1.3 it is the same, so it should be fixed. > > Regards, > Bogdan > > Papadopoulos Georgios wrote: > > Hello all, > > > > I am running into a strange problem with message (or transaction) > > flags. I set a message flag while processing the INVITE, > but this flag > > does not appear in any messages that belong to the same > transaction. I > > discovered this while trying to resolved an issue with > Re-INVITEs. Now > > I am testing it with a simple INVITE-CANCEL senario and I see that > > again the flag does not appear when processing the CANCEL. > My script > > is pretty basic, at least for the CANCEL processing. The > debug output > > is at the end of the email. > > > > if (is_method("CANCEL")) { > > if (!t_check_trans()) { > > # Must be a CANCEL for a > transaction that has > > not been established. > > # Drop it and the client will resend it. > > exit; > > } > > else xlog("L_ERR","$rm: tran found flags=0x$mF > > bflags=0x$bF\n"); > > .... > > t_relay(); > > } > > Searching on the internet I came across this > > > http://openser.org/dokuwiki/doku.php/modules:1.2.x:t_check_trans_comme > > nts > > > http://caravan5.webcrossing.com/People/emin-gabrielyan/public/070413-o > > penser-transactions/ > > > > So what is the story? Am I doing something wrong? > > > > thank you for any help > > > > George > > > > > > 1(18475) SIP Request: > > 1(18475) method: <CANCEL> > > 1(18475) uri: <sip:2116872933@altecnet.gr;user=phone> > > 1(18475) version: <SIP/2.0> > > 1(18475) parse_headers: flags=2 > > 1(18475) Found param type 232, <branch> = <z9hG4bK-mcodgtqb0696>; > > state=6 > > 1(18475) Found param type 235, <rport> = <n/a>; state=17 > > 1(18475) end of header reached, state=5 > > 1(18475) parse_headers: Via found, flags=2 > > 1(18475) parse_headers: this is the first via > > 1(18475) After parse_msg... > > 1(18475) preparing to run routing scripts... > > 1(18475) parse_headers: flags=100 > > 1(18475) DEBUG:parse_to:end of header reached, state=10 > > 1(18475) DBUG:parse_to: display={}, > > ruri={sip:2116872933@altecnet.gr;user=phone} > > 1(18475) DEBUG: get_hdr_field: <To> [41]; > > uri=[sip:2116872933@altecnet.gr;user=phone] > > 1(18475) DEBUG: to body [<sip:2116872933@altecnet.gr;user=phone> > > ] > > 1(18475) get_hdr_field: cseq <CSeq>: <2> <CANCEL> > > 1(18475) DEBUG:maxfwd:is_maxfwd_present: value = 70 > > 1(18475) DBG:maxfwd:process_maxfwd_header: value 70 decreased to 10 > > 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) > > 1(18475) parse_headers: flags=80 > > 1(18475) DEBUG: add_param: tag=b59u54s6kf > > 1(18475) DEBUG:parse_to:end of header reached, state=29 > > 1(18475) DBUG:parse_to: display={"snom"}, > > ruri={sip:demo2@altecnet.gr} > > 1(18475) parse_headers: flags=200 > > 1(18475) DEBUG: get_hdr_body : content_length=0 > > 1(18475) found end of header > > 1(18475) find_first_route: No Route headers found > > 1(18475) loose_route: There is no Route HF > > 1(18475) grep_sock_info - checking if host==us: 11==10 && > > [altecnet.gr] == [213.5.43.4] > > 1(18475) grep_sock_info - checking if port 5060 matches port 5060 > > 1(18475) grep_sock_info - checking if host==us: 11==10 && > > [altecnet.gr] == [213.5.43.7] > > 1(18475) grep_sock_info - checking if port 5060 matches port 5060 > > 1(18475) grep_sock_info - checking if host==us: 11==10 && > > [altecnet.gr] == [213.5.43.8] > > 1(18475) grep_sock_info - checking if port 5060 matches port 5060 > > 1(18475) grep_sock_info - checking if host==us: 11==10 && > > [altecnet.gr] == [213.5.43.9] > > 1(18475) grep_sock_info - checking if port 5060 matches port 5060 > > 1(18475) grep_sock_info - checking if host==us: 11==12 && > > [altecnet.gr] == [172.31.100.5] > > 1(18475) grep_sock_info - checking if port 5060 matches port 5060 > > 1(18475) parse_headers: flags=78 > > 1(18475) DEBUG: t_lookupOriginalT: searching on hash entry 13236 > > 1(18475) DEBUG: RFC3261 transaction matched, tid=-mcodgtqb0696 > > 1(18475) DEBUG: t_lookupOriginalT: canceled transaction found > > (0xb616b3d8)! > > 1(18475) DEBUG:tm:REF_UNSAFE: after is 1 > > 1(18475) DEBUG: t_lookupOriginalT completed > > 1(18475) CANCEL: tran found flags=0x00000000 bflags=0x00000000 > > 1(18475) route9: CANCEL > sip:2116872933@altecnet.gr;user=phone <null> > > fl=0x00000000 bfl=0x00000000 branch_id=0 > > 1(18475) DEBUG: t_newtran: T on entrance=0xffffffff > > 1(18475) parse_headers: flags=ffffffffffffffff > > 1(18475) parse_headers: flags=78 > > 1(18475) t_lookup_request: start searching: hash=13236, isACK=0 > > 1(18475) DEBUG: RFC3261 transaction matching failed > > 1(18475) DEBUG: t_lookup_request: no transaction found > > 1(18475) DBG: trans=0xb616fc50, callback type 1, id 0 entered > > 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) > > 1(18475) DEBUG:tm:set_timer: relative timeout is 1000000 > > 1(18475) DEBUG: add_to_tail_of_timer[4]: 0xb616fd9c (5200000) > > 1(18475) DEBUG:tm:set_timer: relative timeout is 3 > > 1(18475) DEBUG: add_to_tail_of_timer[0]: 0xb616fdb8 (7) > > 1(18475) DEBUG: e2e_cancel: e2e cancel proceeding > > 1(18475) parse_headers: flags=ffffffffffffffff > > 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) > > 1(18475) WARNING:vqm_resize: resize(0) called > > 1(18475) DEBUG:tm:_reply_light: reply sent out. buf=0x817a358: > > SIP/2.0 2..., shmem=0xb6171780: SIP/2.0 2 > > 1(18475) DEBUG:tm:_reply_light: finished > > 1(18475) DEBUG:tm:t_relay_to: new transaction fwd'ed > > 1(18475) DEBUG:tm:UNREF_UNSAFE: after is 0 > > 1(18475) DEBUG:tm:UNREF_UNSAFE: after is 0 > > 1(18475) DEBUG:destroy_avp_list: destroying list (nil) > > 1(18475) receive_msg: cleaning up > > > > > > Disclaimer > > > > The information in this e-mail and any attachments is > confidential. It > > is intended solely for the attention and use of the named > > addressee(s). If you are not the intended recipient, or person > > responsible for delivering this information to the intended > recipient, > > please notify the sender immediately. Unless you are the intended > > recipient or his/her representative you are not authorized to, and > > must not, read, copy, distribute, use or retain this message or any > > part of it. E-mail transmission cannot be guaranteed to be > secure or > > error-free as information could be intercepted, corrupted, lost, > > destroyed, arrive late or incomplete, or contain viruses. > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.openser.org > > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > >

2 1

Re: [OpenSER-Users] retransmissions after final response
by Vasile Zaharia 30 Oct '07

30 Oct '07

Salut Bogdan, Thank you for your response. I think the reply is correct, because in the log file I can see: 2007-10-15 06:28:48.545|t_lookup.c:824|t_reply_matching|DEBUG: t_reply_matching: reply matched (T=0xb5e98bd8)!\n 2007-10-15 06:28:48.545|t_lookup.c:924|t_check|DEBUG: t_check: end=0xb5e98bd8\n 2007-10-15 06:28:48.546|t_hooks.c:203|run_trans_callbacks|DBG: trans=0xb5e98bd8, callback type 256, id 0 entered\n 2007-10-15 06:28:52.754|timer.c:434|wait_handler|DEBUG: wait_handler : removing 0xb5e98bd8 from table \n 2007-10-15 06:28:52.754|timer.c:714|remove_timer_unsafe|DEBUG: unlinking timer: tl=0xb5e98d54, timeout=364, group=0\n 2007-10-15 06:28:52.753|timer.c:239|delete_cell|DEBUG: delete transaction 0xb5e98bd8\n 2007-10-15 06:28:52.753|timer.c:443|wait_handler|DEBUG: wait_handler : done\n 2007-10-15 06:29:15.378|t_lookup.c:824|t_reply_matching|DEBUG: t_reply_matching: reply matched (T=0xb5e98bd8)!\n 2007-10-15 06:29:15.378|t_lookup.c:924|t_check|DEBUG: t_check: end=0xb5e98bd8\n 2007-10-15 06:29:15.378|t_hooks.c:203|run_trans_callbacks|DBG: trans=0xb5e98bd8, callback type 256, id 0 entered\n 2007-10-15 06:29:19.871|timer.c:434|wait_handler|DEBUG: wait_handler : removing 0xb5e98bd8 from table \n 2007-10-15 06:29:19.871|timer.c:714|remove_timer_unsafe|DEBUG: unlinking timer: tl=0xb5e98d54, timeout=391, group=0\n 2007-10-15 06:29:19.871|timer.c:239|delete_cell|DEBUG: delete transaction 0xb5e98bd8\n 2007-10-15 06:29:19.871|timer.c:443|wait_handler|DEBUG: wait_handler : done\n 2007-10-15 06:29:21.853|t_lookup.c:824|t_reply_matching|DEBUG: t_reply_matching: reply matched (T=0xb5e98bd8)!\n [22569] 2007-10-15 06:29:21.853|t_lookup.c:924|t_check|DEBUG: t_check: end=0xb5e98bd8\n [22569] 2007-10-15 06:29:25.894|timer.c:434|wait_handler|DEBUG: wait_handler : removing 0xb5e98bd8 from table \n 2007-10-15 06:29:25.894|timer.c:714|remove_timer_unsafe|DEBUG: unlinking timer: tl=0xb5e98d54, timeout=397, group=0\n 2007-10-15 06:29:25.894|timer.c:239|delete_cell|DEBUG: delete transaction 0xb5e98bd8\n 2007-10-15 06:29:25.894|timer.c:443|wait_handler|DEBUG: wait_handler : done\n 2007-10-15 06:29:50.049|t_lookup.c:824|t_reply_matching|DEBUG: t_reply_matching: reply matched (T=0xb5e98bd8)!\n 2007-10-15 06:29:50.049|t_lookup.c:924|t_check|DEBUG: t_check: end=0xb5e98bd8\n 2007-10-15 06:29:50.051|t_hooks.c:203|run_trans_callbacks|DBG: trans=0xb5e98bd8, callback type 256, id 0 entered\n 2007-10-15 06:29:55.014|timer.c:434|wait_handler|DEBUG: wait_handler : removing 0xb5e98bd8 from table \n 2007-10-15 06:29:55.014|timer.c:714|remove_timer_unsafe|DEBUG: unlinking timer: tl=0xb5e98d54, timeout=425, group=0\n 2007-10-15 06:29:55.014|timer.c:239|delete_cell|DEBUG: delete transaction 0xb5e98bd8\n 2007-10-15 06:29:55.014|timer.c:443|wait_handler|DEBUG: wait_handler : done\n 2007-10-15 06:31:45.071|t_lookup.c:824|t_reply_matching|DEBUG: t_reply_matching: reply matched (T=0xb5e98bd8)!\n 2007-10-15 06:31:45.071|t_lookup.c:924|t_check|DEBUG: t_check: end=0xb5e98bd8\n 2007-10-15 06:31:45.071|t_hooks.c:203|run_trans_callbacks|DBG: trans=0xb5e98bd8, callback type 256, id 0 entered\n 2007-10-15 06:31:49.834|timer.c:434|wait_handler|DEBUG: wait_handler : removing 0xb5e98bd8 from table \n 2007-10-15 06:31:49.834|timer.c:714|remove_timer_unsafe|DEBUG: unlinking timer: tl=0xb5e98d54, timeout=540, group=0\n 2007-10-15 06:31:49.834|timer.c:239|delete_cell|DEBUG: delete transaction 0xb5e98bd8\n 2007-10-15 06:31:49.834|timer.c:443|wait_handler|DEBUG: wait_handler : done\n Maybe I don't understand it correctly? It's about T=0xb5e98bd8. It gets matched, removed, deleted. Many times. The situation was reproduced using 2 different clients: sipp and a proprietary client (using two opensource libraries: osip and exosip). What do you think? Thanks, Sica. ----- Original Message ---- From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> To: Vasile Zaharia <sicavz(a)yahoo.com> Cc: users(a)openser.org Sent: Tuesday, October 30, 2007 6:35:10 AM Subject: Re: [OpenSER-Users] retransmissions after final response Salut Sica, The problem may reside in two places: 1) the reply is not correct and the client is not able to match it to the sent request (and keeps retransmitting) 2) the client is not able to match (due whatever other bugs) the reply. Salutari, Bogdan Vasile Zaharia wrote: > Hi all, > > > I'm developing a Presence AS OpenSER module (derived from the OpenSER Presence module) > and, from time to time, it happens the next situation: > - AS sends a NOTIFY message > - the client receives the NOTIFY and responds with 200 OK > - AS receives 200 OK response, but it starts to retransmit the original NOTIFY and it > retransmits it until it gets back a 408 Request timeout. > > Please note that I use "tm" module for sending SIP messages, so I don't > handle retransmissions explicitly in my module. > Also, note that it does not happen all the time, but from time to time. > > Does anyone else met a similar situation? > > > Thanks, > Sica. > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[OpenSER-Users] Description function: serialize_branches
by Thiago Maluf 30 Oct '07

30 Oct '07

Can Someone describe to me how work and when use the function serialize_branches! Thanks in advanced, Thiago -- ---------------------------------------------------------------- THIAGO MALUF RESENDE Consultor Voip e Programador WEB (Voip Developer and Web Developer) Tel: +55 21 86042100 e-mail: malufrj(a)gmail.com

2 1

[OpenSER-Users] Acc module question
by [ACTIVENDY] NOC 30 Oct '07

30 Oct '07

Hi, I need to know when a channel of my media gateway is busy (included when the call is still ringing, etc). I have my Openser working with acc module storing in a mysql database. I don't use media proxy server. I can see the media gateway active calls in the acc table calculating the INVITEs whithout BYEs call registers. But I see Openser doesn't insert the INVITE register still and ACK arrives. It means I just can view in my database the number of active calls but i cannot know how many call attempts there's in the media gateway. How can I do to Openser insert the INVITE register to my database when an INVITE messages arrives and don't wait for the ACK message? Thanks in advance, Sergi

2 1

[OpenSER-Users] retransmissions after final response
by Vasile Zaharia 30 Oct '07

30 Oct '07

Hi all, I'm developing a Presence AS OpenSER module (derived from the OpenSER Presence module) and, from time to time, it happens the next situation: - AS sends a NOTIFY message - the client receives the NOTIFY and responds with 200 OK - AS receives 200 OK response, but it starts to retransmit the original NOTIFY and it retransmits it until it gets back a 408 Request timeout. Please note that I use "tm" module for sending SIP messages, so I don't handle retransmissions explicitly in my module. Also, note that it does not happen all the time, but from time to time. Does anyone else met a similar situation? Thanks, Sica. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: [OpenSER-Users] An almost-stable revision in svn?
by Bogdan-Andrei Iancu 30 Oct '07

30 Oct '07

Hi Gregorio, the SVN head is the 1.3 version and it is in testing phase, being prepared to be released in ~ one month. If there are issues you discover with this version, please report in order to be fixed. Regards, Bogdan Gregorio wrote: > > Hi all. > > I am installing openSer Head revision (24-10-2007) with openXcap and I > am facing some strange problems I didn´t had before with some previous > versions. One possibility is that those problems (already posted here) > are related to the revision of svn I downloaded. > > Can somebody tell me a recent revision of openSer code that is more or > less stable? > > It would be very appreciated If someone using a Red Hat, Centos… and > using openSer with ‘mi_xmlrpc’ module could help me. > > Thanks a lot! > > Regards. > > Gregorio. > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users >

1 0

[OpenSER-Users] transaction flags not visible in CANCEL
by Papadopoulos Georgios 30 Oct '07

30 Oct '07

Hello all, I am running into a strange problem with message (or transaction) flags. I set a message flag while processing the INVITE, but this flag does not appear in any messages that belong to the same transaction. I discovered this while trying to resolved an issue with Re-INVITEs. Now I am testing it with a simple INVITE-CANCEL senario and I see that again the flag does not appear when processing the CANCEL. My script is pretty basic, at least for the CANCEL processing. The debug output is at the end of the email. if (is_method("CANCEL")) { if (!t_check_trans()) { # Must be a CANCEL for a transaction that has not been established. # Drop it and the client will resend it. exit; } else xlog("L_ERR","$rm: tran found flags=0x$mF bflags=0x$bF\n"); .... t_relay(); } Searching on the internet I came across this http://openser.org/dokuwiki/doku.php/modules:1.2.x:t_check_trans_comment s http://caravan5.webcrossing.com/People/emin-gabrielyan/public/070413-ope nser-transactions/ So what is the story? Am I doing something wrong? thank you for any help George 1(18475) SIP Request: 1(18475) method: <CANCEL> 1(18475) uri: <sip:2116872933@altecnet.gr;user=phone> 1(18475) version: <SIP/2.0> 1(18475) parse_headers: flags=2 1(18475) Found param type 232, <branch> = <z9hG4bK-mcodgtqb0696>; state=6 1(18475) Found param type 235, <rport> = <n/a>; state=17 1(18475) end of header reached, state=5 1(18475) parse_headers: Via found, flags=2 1(18475) parse_headers: this is the first via 1(18475) After parse_msg... 1(18475) preparing to run routing scripts... 1(18475) parse_headers: flags=100 1(18475) DEBUG:parse_to:end of header reached, state=10 1(18475) DBUG:parse_to: display={}, ruri={sip:2116872933@altecnet.gr;user=phone} 1(18475) DEBUG: get_hdr_field: <To> [41]; uri=[sip:2116872933@altecnet.gr;user=phone] 1(18475) DEBUG: to body [<sip:2116872933@altecnet.gr;user=phone> ] 1(18475) get_hdr_field: cseq <CSeq>: <2> <CANCEL> 1(18475) DEBUG:maxfwd:is_maxfwd_present: value = 70 1(18475) DBG:maxfwd:process_maxfwd_header: value 70 decreased to 10 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) 1(18475) parse_headers: flags=80 1(18475) DEBUG: add_param: tag=b59u54s6kf 1(18475) DEBUG:parse_to:end of header reached, state=29 1(18475) DBUG:parse_to: display={"snom"}, ruri={sip:demo2@altecnet.gr} 1(18475) parse_headers: flags=200 1(18475) DEBUG: get_hdr_body : content_length=0 1(18475) found end of header 1(18475) find_first_route: No Route headers found 1(18475) loose_route: There is no Route HF 1(18475) grep_sock_info - checking if host==us: 11==10 && [altecnet.gr] == [213.5.43.4] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) grep_sock_info - checking if host==us: 11==10 && [altecnet.gr] == [213.5.43.7] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) grep_sock_info - checking if host==us: 11==10 && [altecnet.gr] == [213.5.43.8] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) grep_sock_info - checking if host==us: 11==10 && [altecnet.gr] == [213.5.43.9] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) grep_sock_info - checking if host==us: 11==12 && [altecnet.gr] == [172.31.100.5] 1(18475) grep_sock_info - checking if port 5060 matches port 5060 1(18475) parse_headers: flags=78 1(18475) DEBUG: t_lookupOriginalT: searching on hash entry 13236 1(18475) DEBUG: RFC3261 transaction matched, tid=-mcodgtqb0696 1(18475) DEBUG: t_lookupOriginalT: canceled transaction found (0xb616b3d8)! 1(18475) DEBUG:tm:REF_UNSAFE: after is 1 1(18475) DEBUG: t_lookupOriginalT completed 1(18475) CANCEL: tran found flags=0x00000000 bflags=0x00000000 1(18475) route9: CANCEL sip:2116872933@altecnet.gr;user=phone <null> fl=0x00000000 bfl=0x00000000 branch_id=0 1(18475) DEBUG: t_newtran: T on entrance=0xffffffff 1(18475) parse_headers: flags=ffffffffffffffff 1(18475) parse_headers: flags=78 1(18475) t_lookup_request: start searching: hash=13236, isACK=0 1(18475) DEBUG: RFC3261 transaction matching failed 1(18475) DEBUG: t_lookup_request: no transaction found 1(18475) DBG: trans=0xb616fc50, callback type 1, id 0 entered 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) 1(18475) DEBUG:tm:set_timer: relative timeout is 1000000 1(18475) DEBUG: add_to_tail_of_timer[4]: 0xb616fd9c (5200000) 1(18475) DEBUG:tm:set_timer: relative timeout is 3 1(18475) DEBUG: add_to_tail_of_timer[0]: 0xb616fdb8 (7) 1(18475) DEBUG: e2e_cancel: e2e cancel proceeding 1(18475) parse_headers: flags=ffffffffffffffff 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) 1(18475) WARNING:vqm_resize: resize(0) called 1(18475) DEBUG:tm:_reply_light: reply sent out. buf=0x817a358: SIP/2.0 2..., shmem=0xb6171780: SIP/2.0 2 1(18475) DEBUG:tm:_reply_light: finished 1(18475) DEBUG:tm:t_relay_to: new transaction fwd'ed 1(18475) DEBUG:tm:UNREF_UNSAFE: after is 0 1(18475) DEBUG:tm:UNREF_UNSAFE: after is 0 1(18475) DEBUG:destroy_avp_list: destroying list (nil) 1(18475) receive_msg: cleaning up Disclaimer The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.

2 1

Re: [Serusers] [Serdev] SER Release 2 Query..
by Jiri Kuthan 30 Oct '07

30 Oct '07

At 12:51 29/10/2007, Piyush.Bansal(a)relianceada.com wrote: >Hi Jiri, > >We are quite used to of using ser-0.9.6. Now, since we,re switching to release-2.0.0-rc1 we want some documentation for the same. Are there any documents or pointers from where we can get some write ups for this release. see http://www.iptel.org/doc -jiri >thanx 'n' regds > >[] > > > >Jiri Kuthan <jiri(a)iptel.org> > >10/29/2007 02:35 AM >To >Piyush.Bansal(a)relianceada.com >cc >serusers(a)lists.iptel.org, serdev(a)lists.iptel.org >Subject >Re: [Serusers] [Serdev] SER Release 2 Query.. > > > > >At 06:38 29/10/2007, Piyush.Bansal(a)relianceada.com wrote: > >>Hi jiri, >> >>As per your suggestion, we tried to use release 2-0.0-rc1 for our usage. As far as the scripts are concerned to create database schema, the problem remains the same i.e. in the script there is No Provision For Creating subscriber and uri_db Table. > >In which script? >What subscriber table -- that's no longer in use. > >>And my second problem still remains the same with release 2-0.0-rc1 that the auth module doesn't contain the exported function which were there for challenging the Registering party (www_challenge, etc) at the time of Registration. Plz tell me if there is any other way to challenge the registering party in the new release or we're missing something?????? > >I suppose you are confusing yourself with a variety of versions, and suggest >that you install clean ser, use the config makefile, play with ser_ctl and >get some initial confidence with SER. Using multiple versions on the same >system will for sure not work! > >-jiri > > >>plz reply asap.... >> >>regds, >> >>[] >> >> >> >>Jiri Kuthan <jiri(a)iptel.org> >>Sent by: serusers-bounces(a)lists.iptel.org >> >>10/26/2007 10:20 AM >>To >>Piyush.Bansal(a)relianceada.com, serusers(a)lists.iptel.org, serdev(a)lists.iptel.org >>cc >>Subject >>Re: [Serusers] [Serdev] SER Release 2 Query.. >> >> >> >> >>At 14:49 26/10/2007, Piyush.Bansal(a)relianceada.com wrote: >> >>>Hi All, >>> >>>I want to use SER which works with TLS and MySql - 5.0.*+ both. I think that is there in Release 2.* of SER. >>> >>>While testing with the CVS Release of SER dated 22/10/2007, we faced lot of problems, as there was no provision for sending challenge to the Calling Party at the time of Registration.. And there is no Provision to make subscriber and uri_db table at the time of creation of Data Base schema... >>> >>>Has anybody used this release???? >> >>Which -- CVS/HEAD? That's work in massive progress, I would be surprised if someone was using it >>for other purposes than development. (heavy DB overhaul) >> >>Otherwise 2.0 should be fine with respect to the points you are raising. >> >>-jiri >> >>>Plz tell me if there is anything to do with the configuration or what???? >>> >>>plz reply me ASAP..... >>> >>>thanx in advance.. >>> >>>regds, >>> >>>--Piyush Bansal >>>_______________________________________________ >>>Serdev mailing list >>>Serdev(a)lists.iptel.org >>>http://lists.iptel.org/mailman/listinfo/serdev >> >> >> >>-- >>Jiri Kuthan http://iptel.org/~jiri/ >> >>_______________________________________________ >>Serusers mailing list >>Serusers(a)lists.iptel.org >>http://lists.iptel.org/mailman/listinfo/serusers >> >> > > > >-- >Jiri Kuthan http://iptel.org/~jiri/ >[] > > -- Jiri Kuthan http://iptel.org/~jiri/

1 0

[Serusers] MySQL in SER 2.0
by SIP 29 Oct '07

29 Oct '07

A couple of notes. 1) I've replicated my patched my_con.c file for the new SER 2.0 code. This is a patched file to work with MySQL 5.0.19+ (technically 5.0.X+, but there were problems pre 5.0.19). This is to fix problems with the timeouts that MySQL 5 has imposed on open connections. You can find the patched my_con.c file here: http://www.ideasip.com/support/utils/my_con.c.SER2 And it can be applied the same way as it's applied in SER 0.9.6. See the FAQ: http://www.iptel.org/faq/why_does_my_mysql_5_0_x_connection_time_out_when_u… 2) There are still issues with the mysql.so module compiling properly in SER when using a distro that DOESN'T have the mysql client libraries in /usr/lib/mysql Currently, the MySQL community rpms put the client libs into /usr/lib instead of /usr/lib/mysql: [root@localhost ~]# ldconfig -p | grep -i mysqlclient libmysqlclient_r.so.15 (libc6) => /usr/lib/libmysqlclient_r.so.15 libmysqlclient_r.so (libc6) => /usr/lib/libmysqlclient_r.so libmysqlclient.so.15 (libc6) => /usr/lib/libmysqlclient.so.15 libmysqlclient.so (libc6) => /usr/lib/libmysqlclient.so And for some reason, the SER makefile doesn't LOOK for them there. It will look in /usr/lib/mysql and somewhere in /usr/local/lib, but it will ignore /usr/lib. The problem is, the module compiles just fine with no errors of any kind, but when you run ser, you get the usual: module won't load, undefined symbol: log message -- which is entirely misleading. Is there any chance someone will be updating a) the my_con.c file officially (I submitted a bug back in the 0.9.6 days) for use with mysql 5 (since we've been at that stage for a while now), and b) modifying the makefile to look either in the right place or at least error out when things just aren't going to work correctly. Honestly, if I knew how to do either of these, I would... but I've looked at the makefile, and can't figure out why it's not finding the libs. Just some thoughts. For now, I just symlink the /usr/lib/libmysqlclient* files into /usr/lib/mysql and recompile the module and it works just fine. However, that seems like a less than elegant solution. N.

1 0

Re: [OpenSER-Users] logging 'uri' and myself from openser.cfg
by Christian Schlatter 29 Oct '07

29 Oct '07

Gregorio, Gregorio wrote: > Hi all. > > > > I am having some trouble with the sentence ‘if (uri==myself) ’ in the > config script. The REGISTER request URI is ‘sip:mydomain’ and ‘mydomain’ > is in my ‘hosts’ file and in the database table (‘domain’ table) but in > the log I can see that ‘(uri==myself)’ is false. 'myself' is not a script variable but a language construct and therefor cannot be logged with xlog. You should use the 'alias' core paremeter (http://www.openser.org/dokuwiki/doku.php/core-cookbook:1.2.x#alias) to add SIP domain aliases for your server. 'myself' does not look at the 'domain' table. The list of aliases is printed to stdout when you start openser. /Christian > > Someone can guess what is wrong? > > Is it possible to log the values of ‘uri’ and ‘myself’ with xlog? > > > > Thanks and best regards. > > Gregorio. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users(a)lists.openser.org > http://lists.openser.org/cgi-bin/mailman/listinfo/users

1 0

← Newer
1
2
3
4
5
6
7
...
29
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 October 2007