[SR-Users] Serial forking with equal q-value
Good morning, I have serveral servers who are registered with the same AOR in Kamailio. Every server registers with a Q-value indicating its availability. When a user sends an INVITE request through Kamailio to that AOR, Kamailio should send the request to the server with the best Q-value. Using t_load_contacts I obtain a q-ordered destination set but the t_next_contacts uses parallel forking when there are two servers with the same q-value. Is there any way to tell t_next_contacts to use only ONE destination? Thank you in advance, Regards, -- *Jan **Gaida* Ingeniero Desarrollo Software C/ Marconi 3 (PTM) 28760 Tres Cantos Spain jan.ga...@grupoamper.com | www.grupoamper.com -- This message and any attachments are intended only for the use of the individual to whom they are addressed and it may contain information that is privileged or confidential. If you have received this communication by mistake, please notify us immediately by e-mail or telephone.The storage, recording, use or disclosure of this e-mail and its attachments by anyone other than the intended recipient is strictly prohibited. This message has been verified using antivirus software; however, the sender is not responsible for any damage to hardware or software resulting from the presence of any virus. Este mensaje y cualquier anexo son exclusivamente para la persona a quien van dirigidos y pueden contener información privilegiada o confidencial. Si usted ha recibido esta comunicación por error, le agradecemos notificarlo de inmediato por esta misma vía o por teléfono. Está prohibida su retención, grabación, utilización o divulgación con cualquier propósito. Este mensaje ha sido verificado con software antivirus; sin embargo, el remitente no se hace responsable en caso de que en éste o en los archivos adjuntos haya presencia de algún virus que pueda generar daños en los equipos o programas del destinatario. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Serial forking with equal q-value
Jan Gaida writes: I have serveral servers who are registered with the same AOR in Kamailio. Every server registers with a Q-value indicating its availability. When a user sends an INVITE request through Kamailio to that AOR, Kamailio should send the request to the server with the best Q-value. Using t_load_contacts I obtain a q-ordered destination set but the t_next_contacts uses parallel forking when there are two servers with the same q-value. Is there any way to tell t_next_contacts to use only ONE destination? no, unless you do some hacks of your own. same q value means parallel forking. -- juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Kamailio: MI Command: 'trusted_dump' and 'trusted_reload'
Hi, I'm using 'allow_trusted()' from Permissions module without a problem in a Kamailio 4.0 routing logic. It does just work, but the MI command 'trusted_dump' tells me that the module is not in use: ''' server:/home/jmillan# kamctl fifo trusted_dump 500 Trusted-module not in use ''' Doing a 'trusted_reload' does neither make any query to database to retrieve the data. Other MI commands of same module do work correctly. ie: 'address_reload' or 'address_dump' Note: I have tested in a Kamailio 1.5 and the result is the same. Regards. -- José Luis Millán ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio: MI Command: 'trusted_dump' and 'trusted_reload'
Hi, On 06/21/2013 10:59 AM, José Luis Millán wrote: Hi, I'm using 'allow_trusted()' from Permissions module without a problem in a Kamailio 4.0 routing logic. It does just work, but the MI command 'trusted_dump' tells me that the module is not in use: Seems like there is an issue with the rpc commands using kamcmd as well in kamailio 4: kamcmd permissions.trustedDump error: 500 - Reload failed. No trusted table There *is* a trusted table in DB, and I'm using db_mode=0. Not sure why it tries a reload, maybe a copy/paste issue in the error string. Andreas ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Fwd: Call breaks after 32 seconds (Martin Mou?ka)
Good morning Martin. RFC3261 says: [Page 85] RFC 3261SIP: Session Initiation Protocol June 2002 ... If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15. Why 32 seconds? Because almost always T1 = 500 ms. - 64 * 500ms = 32 segs Why 200 OK are being re-transmited? Because someone in someplace is stopping 200 OKs or ACKs. Look for a router/FW and disable ALG for SIP support. Look for errors on headers. Best regards. -- Eduardo Lejarreta. -Mensaje original- De: sr-users-boun...@lists.sip-router.org [mailto:sr-users-boun...@lists.sip-router.org] En nombre de sr-users-requ...@lists.sip-router.org Enviado el: viernes, 21 de junio de 2013 0:18 Para: sr-users@lists.sip-router.org Asunto: sr-users Digest, Vol 97, Issue 79 Send sr-users mailing list submissions to sr-users@lists.sip-router.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users or, via email, send a message with subject or body 'help' to sr-users-requ...@lists.sip-router.org You can reach the person managing the list at sr-users-ow...@lists.sip-router.org When replying, please edit your Subject line so it is more specific than Re: Contents of sr-users digest... Today's Topics: 1. Fwd: Call breaks after 32 seconds (Martin Mou?ka) -- Message: 1 Date: Wed, 19 Jun 2013 14:36:53 +0200 From: Martin Mou?ka mouck...@gmail.com To: sr-users@lists.sip-router.org Subject: [SR-Users] Fwd: Call breaks after 32 seconds Message-ID: cajy3ant7lg1xgo4zjmsa0j-hfbbztpusvz3kdkwiq7kd6xu...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hello, we have problem here with outbound calls. Many devices for example Zyxel, WELL 8820IP, Interbell and some software clients Ekiga v3.3.2 and SJ Phone drops call after 32 seconds. I think it could be some new standard from 2007, because Ekiga v4.0 seems ok and mentioned hardware devices don't have new firmware since this year. Can you confirm that please? I'm attaching some captures. Thank you -- next part -- An HTML attachment was scrubbed... URL: http://lists.sip-router.org/pipermail/sr-users/attachments/20130619/e37898d a/attachment.html -- next part -- A non-text attachment was scrubbed... Name: ekiga-callee-side.pcapng Type: application/octet-stream Size: 23244 bytes Desc: not available URL: http://lists.sip-router.org/pipermail/sr-users/attachments/20130619/e37898d a/attachment.obj -- next part -- A non-text attachment was scrubbed... Name: ekiga-caller-side.pcap Type: application/octet-stream Size: 419756 bytes Desc: not available URL: http://lists.sip-router.org/pipermail/sr-users/attachments/20130619/e37898d a/attachment-0001.obj -- next part -- A non-text attachment was scrubbed... Name: sjphone-callee-side.pcap Type: application/octet-stream Size: 429984 bytes Desc: not available URL: http://lists.sip-router.org/pipermail/sr-users/attachments/20130619/e37898d a/attachment-0002.obj -- next part -- A non-text attachment was scrubbed... Name: sJphone-caller-side.pcapng Type: application/octet-stream Size: 34856 bytes Desc: not available URL: http://lists.sip-router.org/pipermail/sr-users/attachments/20130619/e37898d a/attachment-0003.obj -- ___ sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users End of sr-users Digest, Vol 97, Issue 79 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio: MI Command: 'trusted_dump' and 'trusted_reload'
Hmm... trusted_dump and trusted_reload work OK to me. Kamailio compiled from git a week ago. On Friday 21 June 2013 10:59:54 José Luis Millán wrote: Hi, I'm using 'allow_trusted()' from Permissions module without a problem in a Kamailio 4.0 routing logic. It does just work, but the MI command 'trusted_dump' tells me that the module is not in use: ''' server:/home/jmillan# kamctl fifo trusted_dump 500 Trusted-module not in use ''' Doing a 'trusted_reload' does neither make any query to database to retrieve the data. Other MI commands of same module do work correctly. ie: 'address_reload' or 'address_dump' Note: I have tested in a Kamailio 1.5 and the result is the same. Regards. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Info and support for Kamailio
We use Kamailio - to register users and load balancing. And Asterisk servers to process calls. In Asterisk - I made sip friend with authorization by IP - and all calls from Kamailio are accepted. In Kamailio - all calls from Asterisk are also accepted. I hate products with Asterisk - for me they are too complicated for normal usage. I prefer to write my scripts and dial plan, and to know perfectly well what happen. Also - Cisco phones are small nightmare. There are so many relatively cheap and good SIP phones which just work On Wed, Jun 19, 2013 at 9:03 PM, Gustavo S yeep...@outlook.com wrote: Hi guys, My name is Gustavo Salazar, I'm from Quito-Ecuador (South-America), and I need some info about Kamailio. I'm studying a Master degree of Networking and Data Communications, and I want to build a VoIP project with Kamailio. I want to integrate Kamailio with Trixbox to improve the security levels of the IP-PBX, also I want to use my cisco ip phones 7960G with them, but I need some help with how and where to configure the Kamailio to be connect to the Trixbox server. I made some research about it, and in some pages I read that I can install Kamailio over some Linux Distro like Ubuntu or CentOS, and in other that I can install it on the asterisk (Trixbox) server itself. Could you help me with some examples of configuration, where to configure the extensions. I think is in Kamailio.cfg file, but I don't know how to do it. Please help me with it. I'll be so grateful with you for this support. Regards from Ecuador Gustavo Salazar ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Regarding Instant messaging using TCP on Kamailio 3.3
Hi All Today i could find some information from the logs. When i tested the command : sudo kamcmd core.tcp_list I get 2 connection ( with 2 users regitred with TCP) But when i try to send message from User 2 to User 1, i see that 1 more connection is added. But here the port is confusing. becuase the other 2 tcp connection shows the rport of the users. But with the 3rd connection the port is shown as 5060.. I feel Kamailio is adding a new TCP connection instead of using the existing connection between the client and Kamailio with the rport number. I read that we can use (force_rport()) , but i could not understand how to use it . Alo when i gave force_rport=yes inside the global parameter of Kamaili.cfg file, i still face the same issue. This issue exists even when User 2 try to call/IM to User 1. my laptop is User 1. But i can send IM/Call User 2 succeessfully. I dont understand how my machine can send IM/call successfully, and why no other user can do the same? Kindly support me On Thu, Jun 20, 2013 at 5:27 PM, Sunil Chandrasekharan sunil.kai...@gmail.com wrote: Hi All, I tested again today by disabling the presence module. Still i could not make TCP based IM working with Kamailio. I checked the tcp-connection-lifetime =3605. Still i get 480 Temperory un available. Step 1 : login/register on two lin phones ( on differnt PC) Step 2: from PC 1 (user A) send message to user B Step 3: user B receive the mesage. Step 4. Send message from User B to User A Result : 480 Temperory unavailable. 1. I feel user A connection is getting closed . Hence not able to reach user A. 2. I also see User A and User B message contruct has 2 Via headers. There is no change or anything abnormal happening. Kindly help me forward to get tcp based IM working between two clients. On Tue, Jun 18, 2013 at 2:27 PM, Sunil Chandrasekharan sunil.kai...@gmail.com wrote: Hi , I used open internet, i really doubt if there is any NAT issue here. But my config file(kamailio.cfg) shows : tcp-connection-lifetime=3605 But i dont know what is the registration expire time . How can i see the registration expire time? also my lin phone sends keep alive right? can you please help me how can i see connection close parameter during forward/reply? i dont know where to set them? Please suggest me the correct link to find tcp paremeter and cook book. On Tue, Jun 18, 2013 at 2:06 PM, Daniel-Constantin Mierla mico...@gmail.com wrote: Hello, On 6/17/13 7:09 AM, Sunil Chandrasekharan wrote: Hi All, I have set up Kamailio 3.3 on Ubuntu machine.I created two user test 1 and test 2. I could use Presence and also i was able to register to Kamailio server and exchange presence status with each other. Details- I used TCP protocol . testing methods - Linphone, a sample application. I am able to register succesfully with (TCP) on to kamailio server using Lin phone and sample application. I am able to update presence status of the users. Issue : When i try to send messages between two users ( using TCP ) 1. from Sample application, when i try to send message, i get 420 temporarily Unavailable error from server. 2. from Lin phone 3.5.2, i was able to send messages ( sue TCP) but when the other user try to reply back , i get same error 480 Temporarily Unavailable. error from server. I want a support to understand why i get error while sending messages with TCP via Kamailio server. I am able to succeesfully send and receive messages when i use UDP from my sample application and Lin phone. if the phones are behind nat, be sure the tcp connection lifetime is higher than the registration expire and that you don't set connection close after forward/reply. Look at core cookbook for the appropriate tcp parameter and config functions. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/**micondahttp://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 * http://asipto.com/u/katu * __**_ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] $DLG_lifetime
Hi Daniel, thank you for your answer. I tried to catch the BYE with event_route[dialog:end] but I'm facing another problem. When the timeout for the dialog is reached Kamailio correctly sends a BYE to the caller and to the callee but in the logs I see this: DEBUG: dialog [dlg_timer.c:240]: start with tl=0x7f10937f0138 tl-prev=0x7f10937b4f20 tl-next=0x7f10937b4f20 (42641998) at 42641998 and end with end=0x7f10937b4f20 end-prev=0x7f10937f0138 end-next=0x7f10937f0138 DEBUG: dialog [dlg_timer.c:243]: getting tl=0x7f10937f0138 tl-prev=0x7f10937b4f20 tl-next=0x7f10937b4f20 with 42641998 DEBUG: dialog [dlg_timer.c:249]: end with tl=0x7f10937b4f20 tl-prev=0x7f10937f0138 tl-next=0x7f10937f0138 and d_timer-first.next-prev=(nil) DEBUG: dialog [dlg_timer.c:282]: tl=0x7f10937f0138 next=(nil) DEBUG: dialog [dlg_req_within.c:302]: sending BYE to caller DEBUG: tm [uac.c:243]: DEBUG:tm:t_uac: next_hop=sip:x...@yyy.yyy.yyy.yyy :;transport=udp DEBUG: tm [uac.c:182]: DEBUG: dlg2hash: 343 DEBUG: dialog [dlg_req_within.c:323]: BYE sent to caller DEBUG: dialog [dlg_req_within.c:302]: sending BYE to callee DEBUG: tm [uac.c:243]: DEBUG:tm:t_uac: next_hop=sip:x...@yyy.yyy.yyy.yyy :;transport=udp DEBUG: tm [uac.c:182]: DEBUG: dlg2hash: 343 DEBUG: dialog [dlg_req_within.c:323]: BYE sent to callee DEBUG: dialog [dlg_hash.c:735]: ref dlg 0x7f10937f00e0 with 1 - 3 DEBUG: dialog [dlg_handlers.c:1474]: executing event_route 1 on state 5 DEBUG: dialog [dlg_hash.c:588]: ref dlg 0x7f10937f00e0 with 1 - 4 DEBUG: dialog [dlg_hash.c:590]: dialog id=11591 found on entry 3289 DEBUG: dialog [dlg_hash.c:753]: unref dlg 0x7f10937f00e0 with 1 - 3 DEBUG: dialog [dlg_hash.c:588]: ref dlg 0x7f10937f00e0 with 1 - 4 DEBUG: dialog [dlg_hash.c:590]: dialog id=11591 found on entry 3289 DEBUG: dialog [dlg_hash.c:753]: unref dlg 0x7f10937f00e0 with 1 - 3 DEBUG: core [parser/parse_to.c:799]: end of header reached, state=10 DEBUG: core [parser/msg_parser.c:190]: DEBUG: get_hdr_field: To [20]; uri=[y...@kamailio.org] DEBUG: core [parser/msg_parser.c:192]: DEBUG: to body [y...@kamailio.org #015#012] DEBUG: core [parser/parse_to.c:176]: DEBUG: add_param: tag=123 DEBUG: core [parser/parse_to.c:799]: end of header reached, state=29 DEBUG: core [parser/parse_uri.c:1292]: parse_uri: bad uri, state 0 parsed: you@ (4) / y...@kamailio.org (16) ERROR: core [parser/parse_from.c:113]: failed to parse From uri ERROR: pv [pv_core.c:400]: cannot parse From URI DEBUG: core [parser/parse_uri.c:1292]: parse_uri: bad uri, state 0 parsed: you@ (4) / y...@kamailio.org (16) ERROR: core [parser/parse_to.c:879]: failed to parse To uri ERROR: pv [pv_core.c:394]: cannot parse To URI INFO: script: event_route[dialog:end]: call-id=123 from=null to=null : (method= OPTIONS) :: dlg flag: 18446744073709551615 :: DLG_lifetime: null The parser error problem seems to be related to the To and From headers of FAKED_SIP_MSG, defined in lib/kcore/faked_msg.c. If I change those URIs adding sip: the pv error disappears but once entered the event_route[dialog:end] INFO: script: event_route[dialog:end]: call-id=123 from=you to=you : (method= OPTIONS) :: dlg flag: 18446744073709551615 :: DLG_lifetime: null WARNING: dialog [dlg_req_within.c:177]: inconsitent dlg timer data on dlg 0x7fa07e0c6fe0 [2950:12062] with clid '1518225741' and tags '717826890' '1348505040' As you can see, the $DLG_lifetime is null and we also have the message on the inconsistent dlg timer. Probably there is something that I'm not understanding but why the event_route in this case is processing a fake OPTIONS message? Another thing I noticed is that event_route[dialog:end] is not executed when a dialog is terminated by dlg_end_dlg or dlg_terminate_dlg fifo commands. We really need to access the DLG_lifetime value in both cases (internal timeout or external command), any hint on how to do it? Thank you in advance. Regards, Federico On Fri, Jun 21, 2013 at 12:43 AM, Daniel-Constantin Mierla mico...@gmail.com wrote: Hello, there is an event route for dialog timeout, I guess there is available. tm:local is executed by tm, so you may need to call the function that lookups the dialog. Cheers, Daniel On 6/20/13 1:47 PM, Dragos Oancea wrote: Hello , Is the $DLG_lifetime supposed to be accessed in theevent_route[tm:local-request] ? We are trying to access it and it always reports null with kamailio 4.0.0 . We found a reference about this here: http://www.kamailio.org/pub/kamailio/3.3.3/ChangeLog . dialog(k): run event route after setting cfg dlg vars - in this way they (e.g., $DLG_lifetime) should be accessible in event route (cherry picked from commit 2cdded28d9968a0b78f5ec8329ae6983d9ea77a9) . Apparently it should have been possible. Any hints on this ? Thank you! Regards, Dragos Federico ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
Re: [SR-Users] $DLG_lifetime
Maybe cnxcc module can help you [1]. If you need to set a time limit you could use cnxcc_set_max_time() and when the call times out, an event route is called. [1] http://kamailio.org/docs/modules/devel/modules/cnxcc.html Regards, Carlos On Fri, Jun 21, 2013 at 8:30 AM, Federico Cabiddu federico.cabi...@gmail.com wrote: Hi Daniel, thank you for your answer. I tried to catch the BYE with event_route[dialog:end] but I'm facing another problem. When the timeout for the dialog is reached Kamailio correctly sends a BYE to the caller and to the callee but in the logs I see this: DEBUG: dialog [dlg_timer.c:240]: start with tl=0x7f10937f0138 tl-prev=0x7f10937b4f20 tl-next=0x7f10937b4f20 (42641998) at 42641998 and end with end=0x7f10937b4f20 end-prev=0x7f10937f0138 end-next=0x7f10937f0138 DEBUG: dialog [dlg_timer.c:243]: getting tl=0x7f10937f0138 tl-prev=0x7f10937b4f20 tl-next=0x7f10937b4f20 with 42641998 DEBUG: dialog [dlg_timer.c:249]: end with tl=0x7f10937b4f20 tl-prev=0x7f10937f0138 tl-next=0x7f10937f0138 and d_timer-first.next-prev=(nil) DEBUG: dialog [dlg_timer.c:282]: tl=0x7f10937f0138 next=(nil) DEBUG: dialog [dlg_req_within.c:302]: sending BYE to caller DEBUG: tm [uac.c:243]: DEBUG:tm:t_uac: next_hop=sip:x...@yyy.yyy.yyy.yyy :;transport=udp DEBUG: tm [uac.c:182]: DEBUG: dlg2hash: 343 DEBUG: dialog [dlg_req_within.c:323]: BYE sent to caller DEBUG: dialog [dlg_req_within.c:302]: sending BYE to callee DEBUG: tm [uac.c:243]: DEBUG:tm:t_uac: next_hop=sip:x...@yyy.yyy.yyy.yyy :;transport=udp DEBUG: tm [uac.c:182]: DEBUG: dlg2hash: 343 DEBUG: dialog [dlg_req_within.c:323]: BYE sent to callee DEBUG: dialog [dlg_hash.c:735]: ref dlg 0x7f10937f00e0 with 1 - 3 DEBUG: dialog [dlg_handlers.c:1474]: executing event_route 1 on state 5 DEBUG: dialog [dlg_hash.c:588]: ref dlg 0x7f10937f00e0 with 1 - 4 DEBUG: dialog [dlg_hash.c:590]: dialog id=11591 found on entry 3289 DEBUG: dialog [dlg_hash.c:753]: unref dlg 0x7f10937f00e0 with 1 - 3 DEBUG: dialog [dlg_hash.c:588]: ref dlg 0x7f10937f00e0 with 1 - 4 DEBUG: dialog [dlg_hash.c:590]: dialog id=11591 found on entry 3289 DEBUG: dialog [dlg_hash.c:753]: unref dlg 0x7f10937f00e0 with 1 - 3 DEBUG: core [parser/parse_to.c:799]: end of header reached, state=10 DEBUG: core [parser/msg_parser.c:190]: DEBUG: get_hdr_field: To [20]; uri=[y...@kamailio.org] DEBUG: core [parser/msg_parser.c:192]: DEBUG: to body [y...@kamailio.org #015#012] DEBUG: core [parser/parse_to.c:176]: DEBUG: add_param: tag=123 DEBUG: core [parser/parse_to.c:799]: end of header reached, state=29 DEBUG: core [parser/parse_uri.c:1292]: parse_uri: bad uri, state 0 parsed: you@ (4) / y...@kamailio.org (16) ERROR: core [parser/parse_from.c:113]: failed to parse From uri ERROR: pv [pv_core.c:400]: cannot parse From URI DEBUG: core [parser/parse_uri.c:1292]: parse_uri: bad uri, state 0 parsed: you@ (4) / y...@kamailio.org (16) ERROR: core [parser/parse_to.c:879]: failed to parse To uri ERROR: pv [pv_core.c:394]: cannot parse To URI INFO: script: event_route[dialog:end]: call-id=123 from=null to=null : (method= OPTIONS) :: dlg flag: 18446744073709551615 :: DLG_lifetime: null The parser error problem seems to be related to the To and From headers of FAKED_SIP_MSG, defined in lib/kcore/faked_msg.c. If I change those URIs adding sip: the pv error disappears but once entered the event_route[dialog:end] INFO: script: event_route[dialog:end]: call-id=123 from=you to=you : (method= OPTIONS) :: dlg flag: 18446744073709551615 :: DLG_lifetime: null WARNING: dialog [dlg_req_within.c:177]: inconsitent dlg timer data on dlg 0x7fa07e0c6fe0 [2950:12062] with clid '1518225741' and tags '717826890' '1348505040' As you can see, the $DLG_lifetime is null and we also have the message on the inconsistent dlg timer. Probably there is something that I'm not understanding but why the event_route in this case is processing a fake OPTIONS message? Another thing I noticed is that event_route[dialog:end] is not executed when a dialog is terminated by dlg_end_dlg or dlg_terminate_dlg fifo commands. We really need to access the DLG_lifetime value in both cases (internal timeout or external command), any hint on how to do it? Thank you in advance. Regards, Federico On Fri, Jun 21, 2013 at 12:43 AM, Daniel-Constantin Mierla mico...@gmail.com wrote: Hello, there is an event route for dialog timeout, I guess there is available. tm:local is executed by tm, so you may need to call the function that lookups the dialog. Cheers, Daniel On 6/20/13 1:47 PM, Dragos Oancea wrote: Hello , Is the $DLG_lifetime supposed to be accessed in theevent_route[tm:local-request] ? We are trying to access it and it always reports null with kamailio 4.0.0 . We found a reference about this here: http://www.kamailio.org/pub/kamailio/3.3.3/ChangeLog . dialog(k): run event route after setting cfg dlg vars - in this way they (e.g.,
Re: [SR-Users] $DLG_lifetime
Thanks! I'll have a look on this too. Regards, Federico On Fri, Jun 21, 2013 at 2:43 PM, Carlos Ruiz Díaz carlos.ruizd...@gmail.com wrote: Maybe cnxcc module can help you [1]. If you need to set a time limit you could use cnxcc_set_max_time() and when the call times out, an event route is called. [1] http://kamailio.org/docs/modules/devel/modules/cnxcc.html Regards, Carlos On Fri, Jun 21, 2013 at 8:30 AM, Federico Cabiddu federico.cabi...@gmail.com wrote: Hi Daniel, thank you for your answer. I tried to catch the BYE with event_route[dialog:end] but I'm facing another problem. When the timeout for the dialog is reached Kamailio correctly sends a BYE to the caller and to the callee but in the logs I see this: DEBUG: dialog [dlg_timer.c:240]: start with tl=0x7f10937f0138 tl-prev=0x7f10937b4f20 tl-next=0x7f10937b4f20 (42641998) at 42641998 and end with end=0x7f10937b4f20 end-prev=0x7f10937f0138 end-next=0x7f10937f0138 DEBUG: dialog [dlg_timer.c:243]: getting tl=0x7f10937f0138 tl-prev=0x7f10937b4f20 tl-next=0x7f10937b4f20 with 42641998 DEBUG: dialog [dlg_timer.c:249]: end with tl=0x7f10937b4f20 tl-prev=0x7f10937f0138 tl-next=0x7f10937f0138 and d_timer-first.next-prev=(nil) DEBUG: dialog [dlg_timer.c:282]: tl=0x7f10937f0138 next=(nil) DEBUG: dialog [dlg_req_within.c:302]: sending BYE to caller DEBUG: tm [uac.c:243]: DEBUG:tm:t_uac: next_hop=sip:x...@yyy.yyy.yyy.yyy :;transport=udp DEBUG: tm [uac.c:182]: DEBUG: dlg2hash: 343 DEBUG: dialog [dlg_req_within.c:323]: BYE sent to caller DEBUG: dialog [dlg_req_within.c:302]: sending BYE to callee DEBUG: tm [uac.c:243]: DEBUG:tm:t_uac: next_hop=sip:x...@yyy.yyy.yyy.yyy :;transport=udp DEBUG: tm [uac.c:182]: DEBUG: dlg2hash: 343 DEBUG: dialog [dlg_req_within.c:323]: BYE sent to callee DEBUG: dialog [dlg_hash.c:735]: ref dlg 0x7f10937f00e0 with 1 - 3 DEBUG: dialog [dlg_handlers.c:1474]: executing event_route 1 on state 5 DEBUG: dialog [dlg_hash.c:588]: ref dlg 0x7f10937f00e0 with 1 - 4 DEBUG: dialog [dlg_hash.c:590]: dialog id=11591 found on entry 3289 DEBUG: dialog [dlg_hash.c:753]: unref dlg 0x7f10937f00e0 with 1 - 3 DEBUG: dialog [dlg_hash.c:588]: ref dlg 0x7f10937f00e0 with 1 - 4 DEBUG: dialog [dlg_hash.c:590]: dialog id=11591 found on entry 3289 DEBUG: dialog [dlg_hash.c:753]: unref dlg 0x7f10937f00e0 with 1 - 3 DEBUG: core [parser/parse_to.c:799]: end of header reached, state=10 DEBUG: core [parser/msg_parser.c:190]: DEBUG: get_hdr_field: To [20]; uri=[y...@kamailio.org] DEBUG: core [parser/msg_parser.c:192]: DEBUG: to body [ y...@kamailio.org#015#012] DEBUG: core [parser/parse_to.c:176]: DEBUG: add_param: tag=123 DEBUG: core [parser/parse_to.c:799]: end of header reached, state=29 DEBUG: core [parser/parse_uri.c:1292]: parse_uri: bad uri, state 0 parsed: you@ (4) / y...@kamailio.org (16) ERROR: core [parser/parse_from.c:113]: failed to parse From uri ERROR: pv [pv_core.c:400]: cannot parse From URI DEBUG: core [parser/parse_uri.c:1292]: parse_uri: bad uri, state 0 parsed: you@ (4) / y...@kamailio.org (16) ERROR: core [parser/parse_to.c:879]: failed to parse To uri ERROR: pv [pv_core.c:394]: cannot parse To URI INFO: script: event_route[dialog:end]: call-id=123 from=null to=null : (method= OPTIONS) :: dlg flag: 18446744073709551615 :: DLG_lifetime: null The parser error problem seems to be related to the To and From headers of FAKED_SIP_MSG, defined in lib/kcore/faked_msg.c. If I change those URIs adding sip: the pv error disappears but once entered the event_route[dialog:end] INFO: script: event_route[dialog:end]: call-id=123 from=you to=you : (method= OPTIONS) :: dlg flag: 18446744073709551615 :: DLG_lifetime: null WARNING: dialog [dlg_req_within.c:177]: inconsitent dlg timer data on dlg 0x7fa07e0c6fe0 [2950:12062] with clid '1518225741' and tags '717826890' '1348505040' As you can see, the $DLG_lifetime is null and we also have the message on the inconsistent dlg timer. Probably there is something that I'm not understanding but why the event_route in this case is processing a fake OPTIONS message? Another thing I noticed is that event_route[dialog:end] is not executed when a dialog is terminated by dlg_end_dlg or dlg_terminate_dlg fifo commands. We really need to access the DLG_lifetime value in both cases (internal timeout or external command), any hint on how to do it? Thank you in advance. Regards, Federico On Fri, Jun 21, 2013 at 12:43 AM, Daniel-Constantin Mierla mico...@gmail.com wrote: Hello, there is an event route for dialog timeout, I guess there is available. tm:local is executed by tm, so you may need to call the function that lookups the dialog. Cheers, Daniel On 6/20/13 1:47 PM, Dragos Oancea wrote: Hello , Is the $DLG_lifetime supposed to be accessed in theevent_route[tm:local-request] ? We are trying to access it and it always reports null with kamailio 4.0.0 . We found a reference about this here:
[SR-Users] unable to set reason phrase with t_reply when cause code is 6xx
Hi, I am trying to customize the reason phrase using t_reply. I noticed that we can not set the reason phrase when the code is in the 6xx range Kamailio TM is setting the reason phrase to unknown or to a default one. For example : t_reply(603,My custom reason phrase); Will send 603 Decline ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] unable to set reason phrase with t_reply when cause code is 6xx
I am sorry, please ignore this thread , my problem is introduced by another equipment, I was not tracing directly on the server and I was not suspecting it ! U 2013/06/21 16:19:37.914918 46.46.46.46:5060 - 50.50.50.50:5060 SIP/2.0 603 My custom reason phrase. On Fri, Jun 21, 2013 at 3:44 PM, Julien Chavanton jchavan...@gmail.comwrote: Hi, I am trying to customize the reason phrase using t_reply. I noticed that we can not set the reason phrase when the code is in the 6xx range Kamailio TM is setting the reason phrase to unknown or to a default one. For example : t_reply(603,My custom reason phrase); Will send 603 Decline ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] $DLG_lifetime
Just for the sake of completeness, you can get the dialog duration
(equivalent of $DLG_lifetime) using the following construction:
event_route[cnxcc:call-shutdown]
{
$var(duration) = $TS - $dlg(start_ts);
xlog(L_INFO, Call killed after [$var(duration)] sec(s));
unforce_rtp_proxy();
}
On Fri, Jun 21, 2013 at 8:45 AM, Federico Cabiddu
federico.cabi...@gmail.com wrote:
Thanks!
I'll have a look on this too.
Regards,
Federico
On Fri, Jun 21, 2013 at 2:43 PM, Carlos Ruiz Díaz
carlos.ruizd...@gmail.com wrote:
Maybe cnxcc module can help you [1].
If you need to set a time limit you could use cnxcc_set_max_time() and
when the call times out, an event route is called.
[1] http://kamailio.org/docs/modules/devel/modules/cnxcc.html
Regards,
Carlos
On Fri, Jun 21, 2013 at 8:30 AM, Federico Cabiddu
federico.cabi...@gmail.com wrote:
Hi Daniel,
thank you for your answer.
I tried to catch the BYE with event_route[dialog:end] but I'm facing
another problem.
When the timeout for the dialog is reached Kamailio correctly sends a
BYE to the caller and to the callee but in the logs I see this:
DEBUG: dialog [dlg_timer.c:240]: start with tl=0x7f10937f0138
tl-prev=0x7f10937b4f20 tl-next=0x7f10937b4f20 (42641998) at 42641998 and
end with end=0x7f10937b4f20
end-prev=0x7f10937f0138 end-next=0x7f10937f0138
DEBUG: dialog [dlg_timer.c:243]: getting tl=0x7f10937f0138
tl-prev=0x7f10937b4f20 tl-next=0x7f10937b4f20 with 42641998
DEBUG: dialog [dlg_timer.c:249]: end with tl=0x7f10937b4f20
tl-prev=0x7f10937f0138 tl-next=0x7f10937f0138 and
d_timer-first.next-prev=(nil)
DEBUG: dialog [dlg_timer.c:282]: tl=0x7f10937f0138 next=(nil)
DEBUG: dialog [dlg_req_within.c:302]: sending BYE to caller
DEBUG: tm [uac.c:243]: DEBUG:tm:t_uac: next_hop=sip:x...@yyy.yyy.yyy.yyy
:;transport=udp
DEBUG: tm [uac.c:182]: DEBUG: dlg2hash: 343
DEBUG: dialog [dlg_req_within.c:323]: BYE sent to caller
DEBUG: dialog [dlg_req_within.c:302]: sending BYE to callee
DEBUG: tm [uac.c:243]: DEBUG:tm:t_uac: next_hop=sip:x...@yyy.yyy.yyy.yyy
:;transport=udp
DEBUG: tm [uac.c:182]: DEBUG: dlg2hash: 343
DEBUG: dialog [dlg_req_within.c:323]: BYE sent to callee
DEBUG: dialog [dlg_hash.c:735]: ref dlg 0x7f10937f00e0 with 1 - 3
DEBUG: dialog [dlg_handlers.c:1474]: executing event_route 1 on state 5
DEBUG: dialog [dlg_hash.c:588]: ref dlg 0x7f10937f00e0 with 1 - 4
DEBUG: dialog [dlg_hash.c:590]: dialog id=11591 found on entry 3289
DEBUG: dialog [dlg_hash.c:753]: unref dlg 0x7f10937f00e0 with 1 - 3
DEBUG: dialog [dlg_hash.c:588]: ref dlg 0x7f10937f00e0 with 1 - 4
DEBUG: dialog [dlg_hash.c:590]: dialog id=11591 found on entry 3289
DEBUG: dialog [dlg_hash.c:753]: unref dlg 0x7f10937f00e0 with 1 - 3
DEBUG: core [parser/parse_to.c:799]: end of header reached, state=10
DEBUG: core [parser/msg_parser.c:190]: DEBUG: get_hdr_field: To
[20]; uri=[y...@kamailio.org]
DEBUG: core [parser/msg_parser.c:192]: DEBUG: to body [
y...@kamailio.org#015#012]
DEBUG: core [parser/parse_to.c:176]: DEBUG: add_param: tag=123
DEBUG: core [parser/parse_to.c:799]: end of header reached, state=29
DEBUG: core [parser/parse_uri.c:1292]: parse_uri: bad uri, state 0
parsed: you@ (4) / y...@kamailio.org (16)
ERROR: core [parser/parse_from.c:113]: failed to parse From uri
ERROR: pv [pv_core.c:400]: cannot parse From URI
DEBUG: core [parser/parse_uri.c:1292]: parse_uri: bad uri, state 0
parsed: you@ (4) / y...@kamailio.org (16)
ERROR: core [parser/parse_to.c:879]: failed to parse To uri
ERROR: pv [pv_core.c:394]: cannot parse To URI
INFO: script: event_route[dialog:end]: call-id=123 from=null
to=null : (method= OPTIONS) :: dlg flag: 18446744073709551615 ::
DLG_lifetime: null
The parser error problem seems to be related to the To and From headers
of FAKED_SIP_MSG, defined in lib/kcore/faked_msg.c.
If I change those URIs adding sip: the pv error disappears but once
entered the event_route[dialog:end]
INFO: script: event_route[dialog:end]: call-id=123 from=you to=you :
(method= OPTIONS) :: dlg flag: 18446744073709551615 :: DLG_lifetime:
null
WARNING: dialog [dlg_req_within.c:177]: inconsitent dlg timer data on
dlg 0x7fa07e0c6fe0 [2950:12062] with clid '1518225741' and tags '717826890'
'1348505040'
As you can see, the $DLG_lifetime is null and we also have the
message on the inconsistent dlg timer.
Probably there is something that I'm not understanding but why the
event_route in this case is processing a fake OPTIONS message?
Another thing I noticed is that event_route[dialog:end] is not executed
when a dialog is terminated by dlg_end_dlg or dlg_terminate_dlg fifo
commands.
We really need to access the DLG_lifetime value in both cases (internal
timeout or external command), any hint on how to do it?
Thank you in advance.
Regards,
Federico
On Fri, Jun 21, 2013 at 12:43 AM, Daniel-Constantin Mierla
mico...@gmail.com wrote:
Hello,
there is an event route for dialog
Re: [SR-Users] Proposal for dialog: DLG_STATE_EARLY
Hello,
I have some comments related to the patches, as I couldn't dig much into
sources due to traveling constraints. See them inline.
On 6/14/13 2:10 PM, Halina Nowak wrote:
These modifications were implementated for dialogs having PRACK and UPDATE
--- a/modules/dialog/dlg_handlers.cFri Jun 14 13:45:41 2013 +0200
+++ b/modules/dialog/dlg_handlers.cFri Jun 14 13:55:24 2013 +0200
@@ -1249,16 +1249,18 @@
}
if ( (event==DLG_EVENT_REQ || event==DLG_EVENT_REQACK)
- new_state==DLG_STATE_CONFIRMED) {
+ (new_state==DLG_STATE_CONFIRMED ||
new_state==DLG_STATE_EARLY)) {
This above is to catch PRACK, right? UPDATE should be sent after 200ok,
or is allowed also for early dialogs?
timeout = get_dlg_timeout(req);
if (timeout!=default_timeout) {
dlg-lifetime = timeout;
}
-if (update_dlg_timer( dlg-tl, dlg-lifetime )==-1) {
+if (new_state!=DLG_STATE_EARLY) {
+ if (update_dlg_timer( dlg-tl, dlg-lifetime )==-1) {
LM_ERR(failed to update dialog lifetime\n);
+ }
}
-if (update_cseqs(dlg, req, dir)!=0) {
+if ((event != DLG_EVENT_REQACK) (update_cseqs(dlg, req,
dir)!=0)) {
LM_ERR(cseqs update failed\n);
} else {
dlg-dflags |= DLG_FLAG_CHANGED;
--- a/modules/dialog/dlg_hash.cFri Jun 14 13:45:41 2013 +0200
+++ b/modules/dialog/dlg_hash.cFri Jun 14 13:55:24 2013 +0200
@@ -883,6 +883,7 @@
break;
case DLG_EVENT_REQACK:
switch (dlg-state) {
+ case DLG_STATE_EARLY:
case DLG_STATE_CONFIRMED_NA:
dlg-state = DLG_STATE_CONFIRMED;
Here it seems to go to state DLG_STATE_CONFIRMED due to an ACK even
there was no 200ok reply. Why is needed like that or have I
misunderstood something?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dialog: cseq
Hello,
some comments inline.
On 6/14/13 2:03 PM, Halina Nowak wrote:
Proposal for cseq:
cseq numbering:
--- a/modules/dialog/dlg_handlers.cWed Apr 03 13:33:38 2013 +0200
+++ b/modules/dialog/dlg_handlers.cFri Jun 14 13:39:47 2013 +0200
@@ -220,7 +220,7 @@
cseq = (get_cseq(msg))-number;
} else {
/* use the same as in request */
-cseq = dlg-cseq[DLG_CALLER_LEG];
+cseq = dlg-cseq[DLG_CALLEE_LEG];
at quick check, the comment says the cseq is taken from the request
because it is processing the reply in this part of the code.
You change that to take the value of the stored cseq for callee, which
is different than the current processed message.
What was the problem you discovered? Can you give an example to
understand this change?
}
avoid memory leak:
--- a/modules/dialog/dlg_hash.cFri Jun 14 13:40:12 2013 +0200
+++ b/modules/dialog/dlg_hash.cFri Jun 14 13:45:21 2013 +0200
@@ -485,7 +485,14 @@
char *p;
dlg-tag[leg].s = (char*)shm_malloc( tag-len + rr-len +
contact-len );
-dlg-cseq[leg].s = (char*)shm_malloc( cseq-len );
+if(dlg-cseq[leg].s){
+ if (dlg-cseq[leg].len cseq-len) {
+shm_free(dlg-cseq[leg].s);
+dlg-cseq[leg].s = (char*)shm_malloc(cseq-len);
+ }
+}else{
+ dlg-cseq[leg].s = (char*)shm_malloc( cseq-len );
+}
if ( dlg-tag[leg].s==NULL || dlg-cseq[leg].s==NULL) {
LM_ERR(no more shm mem\n);
if (dlg-tag[leg].s)
I see tag is also allocated each time, isn't it exposed to same issue?
You changed only cseq to reuse existing buffer or free the old one and
allocate a bigger one when needed.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
