sr-users March 2011

sr-users@lists.kamailio.org

83 participants
123 discussions

Re: [SR-Users] OPENSER MIB
by Daniel-Constantin Mierla 17 Oct '11

17 Oct '11

Hello Stefan, On 3/14/11 11:03 AM, Stefan Tiedje wrote: > Thanks for the answer. > Maybe I have some older versions of the OPENSER-MIB and the other > related MIB's since I could not find the counter you pointed at. I'm > using a MIB browser for reading the MIB's. > Is the suggested counter "expired dialogs" added in a specific release > of Kamailio? Which? We use Kamailio 3.0.2. I used Kamailio and recommend using it sine it has the latest commits for stability. However, what I wrote before is pretty much not related to the version. There is a counter that tracks the processed dialogs, but seems it is not exported by default through snmpstats module. The statistics counter is named "processed_dialogs", implemented by dialog module. You can dump all internal statistics through kamctl or via xmlrpc command, but probably to export it through snmpstats you may need to extend the mibs and the code of the module. I just grepped the sources of snmpstats module to see what dialog statistics it is exporting: $ grep -n _dialogs modules_k/snmpstats/* | grep get_statistic modules_k/snmpstats/alarm_checks.c:83: num_dialogs = get_statistic("active_dialogs"); modules_k/snmpstats/snmpObjects.c:404: int result = get_statistic("active_dialogs"); modules_k/snmpstats/snmpObjects.c:424: get_statistic("active_dialogs") - modules_k/snmpstats/snmpObjects.c:425: get_statistic("early_dialogs"); modules_k/snmpstats/snmpObjects.c:443: int result = get_statistic("early_dialogs"); modules_k/snmpstats/snmpObjects.c:459: int result = get_statistic("failed_dialogs"); modules_k/snmpstats/snmpObjects.c:508: int num_dialogs = get_statistic("active_dialogs"); Perhaps when the snmpstats was developed the dialog module didn't export the statistics counter of "processed_dialogs" and then it was not updated. Now, what I tried to say is that if the "processed_dialogs" counter is not available through snmpstats (and it is not now after grepping the sources) you can get its value from another application through "kamctl get_statistics all" or XMLRPC command for all of the existing kamailio releases. Upcoming one we will look to implement the export through snmpstats as well. If you have time to do it and send us a patch, we will gladly commit it to source tree in our GIT repository. Cheers, Daniel > Do you have the MIB name for the "expired dialogs" counter. I will > look for that in my version of OPENSER MIBS. > Important, do you have a link to where MIB files can be downloaded for > Kamailio 3.0.2? > Below follows an excerp from one of the MIB's. Is it old, I don't know? > > -- *********************************************************************** > > -- OPENSER-MIB: OPENSER MIB > > -- > > -- Date of Creation: Januay 2006 > > -- > > -- This MIB provides information related to the OpenSER SIP Router. > > -- > > -- Copyright (c) The Internet Society (2006) > > -- Ammendments (c) Soma Networks, Inc. (2006) > > -- > > -- All rights reserved. > > -- ***************************************************************** > > /Stefan > > ------------------------------------------------------------------------ > *From:* Daniel-Constantin Mierla [mailto:miconda@gmail.com] > *Sent:* den 14 mars 2011 10:16 > *To:* Stefan Tiedje > *Cc:* sr-users(a)lists.sip-router.org > *Subject:* Re: [SR-Users] OPENSER MIB > > Hello, > > On 3/14/11 9:42 AM, Stefan Tiedje wrote: >> Hi, >> In the Kamailio OPENSER-MIB there is the counter >> "openserTotalNumFailedDialogSetups". This is a Counter32. >> The description is: >> "The total number of calls that failed with an error. The >> following codes define a failed call:" >> *Question:* >> >> * I'm looking for the corresponding counter to >> "openserTotalNumFailedDialogSetups" who counts successful >> Dialog setups of Counter32 type. Does it exist? >> * If not, does it exist a work around? >> * Where in the code can the new suggested counter be added? >> * Something else???? >> > > the dialog module counts the number of processed dialogs, see: > http://kamailio.org/docs/modules/stable/modules_k/dialog.html#id2966360 > > There is no counter currently inside dialog module exporting exactly > the number of successfully setup dialogs, it should not be hard to do > it, though. Using the above and the number of failed and expired > dialogs, you can actually get the number of successful dialogs. > > Dialog module being the one that tracks SIP dialogs, therefore being > able to count them, now I don't know if snmpstats module exports all > the counters from dialog module. I setup snmpstats just few weeks ago > and works perfect on Ubuntu/Debian servers, but I had no need to check > dialog module counters. > > Note that you can get the list of all internal statistics via kamctl: > - kamctl fifo get_statistics all > > Or via XMLRPC if you need them remotely in another application. > > Another option is to define your statistics with statistics module. > Knowing that in SIP a successful call dialog means 200ok reply to an > INVITE transaction, you can count it in the onreply_route[abc] that > you arm for relayed transactions with t_on_reply("abc"). > > Hope these help you, > Daniel > >> Suggestion for the new counter is a name like: >> "openserTotalNumSucceededDialogSetups". It has a counter32. >> Description: "The total number of calls that succeeded" >> I know that there are the counters openserCurNumDialogs, >> openserCurNumDialogsInProgress and openserCurNumDialogsInSetup but >> these are of Gauge type who only reflects the current situation. >> These Gauge counters can't be used together with a Counter32 counter. >> That don't mix. The calculation done for the counter >> "openserCurNumDialogsInProgress" should be used where every new >> dialog setup is added to the new suggested counter. A counter of 32 >> should cover a great deal of connections. These counters are usually >> read, if used, every 15 minutes or 1 hour. >> *Rationale:* >> The reason for the new counter is that a calculation between >> succeeded and failed dialog setups can be done and be used for SLA >> agreements. Without this, its hard to make any customer versus >> provider agreements. >> /Stefan >> PS. Ask if anything is unclear and I need an answer rapidly. >> >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla > http://www.asipto.com -- Daniel-Constantin Mierla http://www.asipto.com

2 5

Float Comparison
by Brandon Armstead 25 Aug '11

25 Aug '11

Hello, Is there anything special that needs to be done for float comparison? For example: if([5.5 >= 4.3]) .... or if(5.5 > 4.3) .... The conditional does not seem to be coming back as true like it should? This is simply an example... the precision in the actual case is different (longer decimal places). Thank you for all and any help in advance!

4 9

SEMS 1.4.0 release
by Stefan Sayer 24 May '11

24 May '11

We are happy to announce the availability of the SIP Express Media Server version 1.4.0. SEMS is a high performance media and application server for SIP based VoIP networks. This release features a powerful Session Border Controller (SBC) module. From completely transparent B2BUA to customized URI/From/To, strictly filtered (messages, headers, codecs) with RTP anchoring, Session Timer enforcement, prepaid and call timer, the SBC facilitates interconnect and core routing in a simple and secure way. Thanks to the new multihoming support, SEMS can now be employed at the border of the networks. This addition also allows to overcome the bottleneck of one NIC - giving the possibility to fully exploit SEMS' great performance. In the app development area, the DSM language has matured to become a viable candidate also for implementing complex application logic, thanks to language constructs like for, if and functions. SEMS can be downloaded in source from its ftp site at: ftp.iptel.org/pub/sems/1.4/1.4.0/ Packages for debian/ubuntu should appear shortly on the OBS page: https://build.opensuse.org/project/show?project=home:team-sems Contributors to this release: Stefan Sayer, Raphael Coeffic, Bogdan Pintea, Matthew Williams, Peter Lemenkov, Anton Zagorskiy, Robert Szokovacs, Jon Bonilla, Thomas Gelf, Erik Dekkers, Tobias Lindgren, David J Many thanks to the companies sponsoring SEMS development, especially FRAFOS GmbH and TelTech Systems Inc. "E stands for Express." * Apologies if you receive multiple copies of this message. *

4 5

Bug in LDAP module?
by Pan B. Christensen 26 Apr '11

26 Apr '11

Hello, We are using kamailio 1.5 and we have the following problem with ldap_search: A call comes in. If it is to a VOIP user, it will be routed to kamailio, and eventually go to the ldap lookup route: route[10] to look up the user. This is always successful (LDAP can connect). It will then look up user preferences (call forwarding etc.) from SQL in route[12] and route based on this result in route[13]. If the result is "CFU (call forward unconditional) = on", the URI is changed and route[10] (LDAP lookup) is called again. This is always successful (LDAP can connect). If the result is "CFB (call forward busy) = on" and the user is busy, the URI is changed and route[10] (LDAP lookup) is called again. This is also always successful (LDAP can connect). If the result is "CFNR (call forward no reply) = on", the timeout is changed and the call is delivered to the phone through route[14] (location) and route[15] (relay). If the user does not answer, the URI is changed in failure_route[1] and route[10] is called. For some unknown reason, ldap_search always fails in this scenario with the messages: "ldap_session not found", "couldn't get ldap session" and then "no LDAP entry found". Why? And why does this result in the -1 return code and not the -2 return code for ldap_search? The only differences I can think of is that the unsuccessful scenario comes from FAILURE_ROUTE instead of REQUEST_ROUTE, and that longer time has passed since the original invite. Here's a sample log: NOTE the three ERROR lines, the INFO line and the ROUTE 10 line. Dec 27 13:31:55 [3373]: INVITE received from sip:<CALLER>@<SBC_IP> <source IP: <SBC_IP>> to sip:<CALLEE>@<KAM_IP>: Dec 27 13:31:55 [3373]: ERROR:ldap:ldap_reconnect: [ldapprod]: LDAP reconnect successful Dec 27 13:31:55 [3373]: ROUTE 10: LDAP returned: UID = <UID>, voipSipPrimaryUri = <PRIMARY_URI>, voipExtensionUri = sip:<CALLEE>@<DOMAIN> Dec 27 13:31:55 [3373]: ROUTE 12: Effective user properties for UID <UID>: CFU: off <FORWARDTO>, CFB: off <FORWARDTO>, CFNR: on:25 <FORWARDTO>, CFNC: off <FORWARDTO>, VM: <CALLEE>, busy_level: 1, DBrows: 1 Dec 27 13:31:55 [3373]: -------------------- Calling sip:<CALLEE>@<DOMAIN> for 25 seconds. -------------------- Dec 27 13:31:55 [3373]: ROUTE 15: Sending 105 INVITE from sip:<CALLER>@<SBC_IP> to sip:<CALLEE>@<CALLEE_IP> (via <<null>>) Dec 27 13:31:55 [3383]: Response 100 Trying to Cseq 102 INVITE received from <PROTO>:<CALLEE_IP>:<PORT> Dec 27 13:31:55 [3385]: Response 180 Ringing to Cseq 102 INVITE received from <PROTO>:<CALLEE_IP>:<PORT> Dec 27 13:32:20 [3388]: FAILURE_ROUTE 1: Timeout for: 104 INVITE from <CALLER> -> <CALLEE> Dec 27 13:32:20 [3388]: -------------------- Forwarding on no reply to <FORWARDTO> -------------------- Dec 27 13:32:20 [3388]: ERROR:ldap:get_connected_ldap_session: [ldapprod]: ldap_session not found Dec 27 13:32:20 [3388]: ERROR:ldap:lds_search: [ldapprod]: couldn't get ldap session Dec 27 13:32:20 [3388]: INFO:ldap:ldap_search_impl: no LDAP entry found Dec 27 13:32:20 [3388]: ROUTE 11: Number lookup results for <FORWARDTO>: Node: VOIP. Dec 27 13:32:20 [3388]: CONFIG ERROR: VOIP number not found in LDAP. Hanging up. Dec 27 13:32:20 [3373]: Response 487 Request Cancelled to Cseq 102 INVITE received from <PROTO>:<CALLEE_IP>:<PORT> Here's the ldap config file: [ldapprod] ldap_server_url = "ldap://ldap.<DOMAIN>" ldap_network_timeout = 500 ldap_client_bind_timeout = 500 kamailio config snippets (in case you need them): # LDAP lookup for UID and primary URI route[10] { ... ldap_search("ldap://ldapprod/<DN>?uid,voipSipPrimaryUri,voipExtensionUri?one?(&(objectClass=voipAddress)(|(voipSipUri=sip:$rU@uio.no)(|(voipSipUri=$var(uri))(voipSipUri=$var(e164uri)))))"); if ($retcode < 1) { switch ($retcode) { case -1: # no LDAP entry found route(11); return(1); case -2: # internal error sl_send_reply("500", "Internal server error"); exit; } } ldap_result("uid/$avp(s:uid)"); $avp(s:exten) = null; if (!ldap_result("voipExtensionUri/$avp(s:exten)")) { xlog("L_INFO", "voipExtensionUri not found.\n"); } if (!ldap_result("voipSipPrimaryUri/$avp(s:p-uri)")) { xlog("L_WARN", "voipSipPrimaryUri not found.\n"); #exit here? } if (isflagset(1)) { xlog("L_INFO", "ROUTE 10: LDAP returned: UID = $avp(s:uid), voipSipPrimaryUri = $avp(s:p-uri), voipExtensionUri = $avp(s:exten)\n"); } if $avp(s:exten) != null { $ru=$avp(s:exten); } else { $ru=$avp(s:p-uri); } route(12); } } # Number lookup. Non-VoIP URI's go here. route[11] { ... } # Database lookup for call forwarding. route[12] { ... } # Call forwarding logic route[13] { if (is_method("INVITE")) { $avp(s:uio_timer_avp) = "300"; if ($avp(s:cfu_status) == "on") { # Forward immediately xlog("L_INFO", "-------------------- $rU forwarded unconditionally to $avp(s:cfu_number). --------------------\n"); $rU = $avp(s:cfu_number); route(10); } ... if ( $var(dlg_busy) >= $avp(s:busy_level) ) { if ($avp(s:cfb_status) == "on") { xlog("L_INFO", "-------------------- $rU has $var(dlg_busy) active calls. Treshold $avp(s:busy_level). Forwarding on busy to $avp(s:cfb_number) --------------------\n"); $rU = $avp(s:cfb_number); route(10); } ... else if ($avp(s:cfnr_status) == "on") { # Forward to phone with timeout then to $avp(s:cfnr_number). # t_set_fr($avp(s:cfnr_timeout) + "000"); # Recommended method in 3.1. Function does not exist in 1.5. Using old method (avp). $avp(s:uio_timer_avp) = $avp(s:cfnr_timeout); xlog("L_INFO", "-------------------- Calling $ru for $avp(s:uio_timer_avp) seconds. --------------------\n"); route(14); } ... } failure_route[1] { ... if $avp(s:cfnr_status) == "on" { if (isflagset(1)) { xlog("L_INFO", "FAILURE_ROUTE 1: Timeout for: $mi $rm from $fU -> $rU\n"); } revert_uri(); $rU = $avp(s:cfnr_number); xlog("L_INFO", "-------------------- Forwarding on no reply to $rU --------------------\n"); route(10); } ... } With kind regards, Pan

3 5

stats in kamailio
by Ricardo Martinez 19 Apr '11

19 Apr '11

Hello. I’m trying to get statistics to use charts in SIREMIS v2.0. I was able to load the “Memory” statistics but I want to know if there is more information to use from Kamailio, right now I have : $stat(used_size) $stat(real_used_size) $stat(max_used_size) $stat(free_size) $stat(location-users) $stat(location-contacts) Where can I find the complete list of statistics to get from kamailio?. Thanks in advance. Ricardo Martinez.-

5 13

"kamctl fifo debug" does not work
by Klaus Darilion 07 Apr '11

07 Apr '11

root@pbx-kam-1:/home/klaus3000# kamctl fifo debug DEBUG:: 2 root@pbx-kam-1:/home/klaus3000# kamctl fifo debug 0 DEBUG:: 0 Mar 9 11:04:23 pbx-kam-1 /usr/sbin/kamailio[4548]: INFO: <core> [cfg/cfg_ctx.c:411]: INFO: cfg_set_now(): core.debug has been changed to 0 but: root@pbx-kam-1:/home/klaus3000# kamctl fifo debug DEBUG:: 2 Is this a bug? regards Klaus

2 2

Kamailio at Google Summer of Code 2011
by Daniel-Constantin Mierla 07 Apr '11

07 Apr '11

Hello, for the second year, Kamailio is participating in GSoC program. For 2011, the proposal is to implement a signaling gateway between SIP and JINGLE to enable voice calls between the two networks: http://www.jitsi.org/index.php/GSOC2011/KamailioJingle If you are a student, or you know a student, interested in this project, just write me or to sr-dev(a)lists.sip-router.org. The application starts today and the deadline is April 8, therefore it is quite a short period, you will have to hurry. You can read more about the GSoC program and Kamailio at: http://www.kamailio.org/w/gsoc-2011/ http://www.jitsi.org/index.php/Development/Gsoc2011 Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

7 15

tcp hangup
by Juha Heinanen 05 Apr '11

05 Apr '11

i have two sr proxies talking with each other over tcp. one is running 3.0 and the other 3.1. sometimes i notice that no sip requests or any other tcp packets get through from 3.0 sr host to 3.1 sr host. netstat on 3.0 sr host shows that tcp connection to 3.1 sr host is in ESTABLISHED state whereas netstat on 3.1 sr shows that the same tcp connection is in FIN_WAIT1 state. it takes several minutes before the hanging tcp connection is replaced by a new working one. there is no ip level connectivity problem between the two sr hosts. any suggestions on what might be going on? is there some known bug in 3.0 tcp implementation that could explain this? -- juha

3 12

SIP NOTIFY problem in "presence_dialoginfo" module?
by Klaus Feichtinger 04 Apr '11

04 Apr '11

Hello list, I have a special situation in which string characters of the "root-line" of the notify-body are overwritten by Kamailio. In detail: the root-line of the NOTIFY message sent to the subscriber looks like: <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" ll" entity="sip:117090@10.16.10.99"> instead of <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full" entity="sip:117090@10.16.10.99"> In other words: the string state="full" is overwritten by space characters. Therefore the message is no longer "valid" and the parser of the subscriber-user agent has problems.... The exact scenario in my use case is, that user agents can subscribe the events "presence" and "dialog" on Kamailio. The information about presence and dialog-states is published to Kamailio by PUBLISH messages from the user agents themselves. Kamailio does not have to generate this information itself. In the following lines I have an excerpt of the signalisation: 1) initial subscription of party A, 2) the responded notification (without body) 3) subscription of party B 4) the responded notification (with body) 5) a publish message of the subscribed party B with actual dialog information and 6) the notification with body to the subscriber A. 1) Initial SUBSCRIBE message of party A: ======================================SUBSCRIBE sip:117090@10.16.10.99 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.93:5060;rport;branch=z9hG4bK1411449981 From: <sip:117093@10.16.10.99>;tag=2453899634-24035392-1301468026894 To: <sip:117090@10.16.10.99> Call-ID: 2442490492-24035392-1301468026894(a)10.16.10.93 CSeq: 20 SUBSCRIBE Contact: <sip:117093@10.16.10.93:5060> Max-Forwards: 70 User-Agent: SipTapi Expires: 3600 Event: dialog Content-Length: 0 2) Responded NOTIFY message from Kamailio: ========================================NOTIFY sip:117093@10.16.10.93:5060 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.99;branch=z9hG4bK7cc7.08e060b6000000000000000000000000.0 To: sip:117093@10.16.10.99;tag=2453899634-24035392-1301468026894 From: sip:117090@10.16.10.99;tag=a23c71953194c2c72e41c4d20e4f7127-86e1 CSeq: 1 NOTIFY Call-ID: 2442490492-24035392-1301468026894(a)10.16.10.93 Content-Length: 0 User-Agent: kamailio (3.1.2 (i386/linux)) Max-Forwards: 70 Event: dialog Contact: <sip:10.16.10.99:5060> Subscription-State: active;expires=3670 3) Initial SUBSCRIBE message of party B: ======================================SUBSCRIBE sip:117093@10.16.10.99 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.90:5060;rport;branch=z9hG4bK4016956575 From: <sip:117090@10.16.10.99>;tag=2605346227-26329880-1301468174702 To: <sip:117093@10.16.10.99> Call-ID: 2982039389-26329880-1301468174702(a)10.16.10.90 CSeq: 20 SUBSCRIBE Contact: <sip:117090@10.16.10.90:5060> Max-Forwards: 70 User-Agent: SipTapi Expires: 3600 Event: dialog Content-Length: 0 4) Responded NOTIFY message from Kamailio (with version number "00000000000"!!!!): ==============================================================================NOTIFY sip:117090@10.16.10.90:5060 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.99;branch=z9hG4bK10e8.31cb2284000000000000000000000000.0 To: sip:117090@10.16.10.99;tag=2605346227-26329880-1301468174702 From: sip:117093@10.16.10.99;tag=a23c71953194c2c72e41c4d20e4f7127-5f56 CSeq: 1 NOTIFY Call-ID: 2982039389-26329880-1301468174702(a)10.16.10.90 Content-Length: 593 User-Agent: kamailio (3.1.2 (i386/linux)) Max-Forwards: 70 Event: dialog Contact: <sip:10.16.10.99:5060> Subscription-State: active;expires=3670 Content-Type: application/dialog-info+xml <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="00000000000" state="full" entity="117093(a)10.16.10.99"> <dialog id="3375446242-26591296-1301467877329(a)10.16.10.93" call-id="3375446242-26591296-1301467877329(a)10.16.10.93" direction="initiator"> <state>terminated</state> <remote> <identity>sip:019992116002@10.16.10.99</identity> <target uri="sip:019992116002@10.16.10.99"/> </remote> <local> <identity>sip:117093@10.16.10.99</identity> <target uri="sip:117093@10.16.10.99"/> </local> </dialog> </dialog-info> 5) The subscribed party is sending a PUBLISH message with following information: ============================================================================PUBLISH sip:117090@10.16.10.99 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.90:5060;rport;branch=z9hG4bK348084694 From: <sip:117090@10.16.10.99>;tag=3644648667-26329880-1301468223499 To: <sip:117090@10.16.10.99> Call-ID: 332031778-26329880-1301468223499(a)10.16.10.90 CSeq: 20 PUBLISH Max-Forwards: 70 User-Agent: SipTapi Content-Disposition: render;handling=required Expires: 3600 Event: dialog Content-Type: application/dialog-info+xml Content-Length: 592 <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="4" state="full" entity="sip:117090@10.16.10.99"> <dialog id="2769397361-26329880-1301468223108(a)10.16.10.90" call-id="2769397361-26329880-1301468223108(a)10.16.10.90" direction="initiator"> <state>confirmed</state> <remote> <identity><sip:116001@10.16.10.99></identity> <target uri="<sip:116001@10.16.10.99>"/> </remote> <local> <identity>sip:117090@10.16.10.99</identity> <target uri="sip:117090@10.16.10.99"/> </local> </dialog> </dialog-info> 6) Status informative NOTIFY message from Kamailio (built from the PUBLISH message above - with correct version but string overwriting!!!): =======================================================================================================================================NOTIFY sip:117093@10.16.10.93:5060 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.99;branch=z9hG4bK4cc7.faa8dc87000000000000000000000000.0 To: sip:117093@10.16.10.99;tag=2453899634-24035392-1301468026894 From: sip:117090@10.16.10.99;tag=a23c71953194c2c72e41c4d20e4f7127-86e1 CSeq: 2 NOTIFY Call-ID: 2442490492-24035392-1301468026894(a)10.16.10.93 Content-Length: 592 User-Agent: kamailio (3.1.2 (i386/linux)) Max-Forwards: 70 Event: dialog Contact: <sip:10.16.10.99:5060> Subscription-State: active;expires=3570 Content-Type: application/dialog-info+xml <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" ll" entity="sip:117090@10.16.10.99"> <dialog id="2769397361-26329880-1301468223108(a)10.16.10.90" call-id="2769397361-26329880-1301468223108(a)10.16.10.90" direction="initiator"> <state>confirmed</state> <remote> <identity><sip:116001@10.16.10.99></identity> <target uri="<sip:116001@10.16.10.99>"/> </remote> <local> <identity>sip:117090@10.16.10.99</identity> <target uri="sip:117090@10.16.10.99"/> </local> </dialog> </dialog-info> Debug information of Kamailio and information in the source code show that the version number "00000000000" is a placeholder only, which should be replaced with a valid version number. However, it seems that there is a problem in handling these strings. The version number is replaced, but in case that the version id is only one character long, ten space characters are inserted- overwriting other information...... Can anybody comment this problem? Is this a bug of the presence_dialoginfo- or another module? Thanks in advance! Regards, Klaus P.S. additional information from source code an debug output of kamailio: notify_body.c: [...] /* The version must be increased for each new document and is a 32bit int. As the version is different for each watcher, we can not set here the correct value. Thus, we just put here a placeholder which will be replaced by the correct value in the aux_body_processing callback. Thus we have CPU intensive XML aggregation only once and can use quick search&replace in the per-watcher aux_body_processing callback. We use 11 chracters as an signed int (although RFC says unsigned int we use signed int as presence module stores "version" in DB as signed int) has max. 10 characters + 1 character for the sign */ [...] Debug information from Kamailio: Ad 4) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:67]: [pres_user]=117093 [pres_domain]= 10.16.10.99, [n]=1 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:107]: [pres_user]=117093 [pres_domain]= 10.16.10.99, [n]=1 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:199]: node type: Element, name: dialog SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:73]: [n_body]=0x835fe54 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:76]: [*n_body]=<?xml version="1.0"?>#012<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="00000000000" state="full" entity="117093(a)10.16.10.99">#012 <dialog id="6b1de4df-6c9ce978(a)10.16.10.203" call-id="6b1de4df-6c9ce978(a)10.16.10.203" direction="recipient">#012 <state>confirmed</state>#012 <remote>#012 <identity>sip:116001@10.16.10.99</identity>#012 <target uri="sip:116001@10.16.10.99"/>#012 </remote>#012 <local>#012 <identity>sip:117093@10.16.10.99</identity>#012 <target uri="sip:117093@10.16.10.99"/>#012 </local>#012 </dialog>#012</dialog-info>#012 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:328]: replace version with "1" SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:1461]: dialog info: SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:122]: #012#011[pres_uri]= sip:117093@10.16.10.99#012#011[to_user]117093#011[to_domain]= 10.16.10.99#012#011[w_user]= 117090#011[w_domain]10.16.10.99#012#011[event]= dialog#012#011[status]= active#012#011[expires]3519#012#011[callid]3119346140-8635704-1301477522967(a)10.16.10.90#011[local_cseq]=1#012#011[to_tag ]= a23c71953194c2c72e41c4d20e4f7127-7529#011[from_tag]2282475328-8635704-1301477522967#012#011[contact]sip:117090@10.16.10.90:5060#011[record_route]SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:234]: expires 3519 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:1555]: headers:#012Max-Forwards: 70#015#012Event: dialog#015#012Contact: <sip:10.16.10.99:5060>#015#012Subscription-State: active;expires=3570#015#012Content-Type: application/dialog-info+xml#015#012 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:940]: CONTACT sip:117090@10.16.10.90:5060 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 11==11 && [10.16.10.99] =[10.16.10.99] SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5060 matches port 5060 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:1729]: ==22/6/37 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: tm [uac.c:240]: DEBUG:tm:t_uac: next_hop=<sip:117090@10.16.10.90:5060> SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: tm [uac.c:181]: DEBUG: dlg2hash: 27355 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: INFO: presence [notify.c:1586]: NOTIFY sip:117090@10.16.10.99 via sip:117090@10.16.10.90:5060 on behalf of sip:117093@10.16.10.99 for event dialog Ad 6) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:67]: [pres_user]=117093 [pres_domain]= 10.16.10.99, [n]=1 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:107]: [pres_user]=117093 [pres_domain]= 10.16.10.99, [n]=1 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:199]: node type: Element, name: dialog SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:73]: [n_body]=0x835fcb0 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:76]: [*n_body]=<?xml version="1.0"?>#012<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="00000000000" state="full" entity="117093(a)10.16.10.99">#012 <dialog id="6b1de4df-6c9ce978(a)10.16.10.203" call-id="6b1de4df-6c9ce978(a)10.16.10.203" direction="recipient">#012 <state>terminated</state>#012 <remote>#012 <identity>sip:116001@10.16.10.99</identity>#012 <target uri="sip:116001@10.16.10.99"/>#012 </remote>#012 <local>#012 <identity>sip:117093@10.16.10.99</identity>#012 <target uri="sip:117093@10.16.10.99"/>#012 </local>#012 </dialog>#012</dialog-info>#012 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence_dialoginfo [notify_body.c:328]: replace version with "2" SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:1461]: dialog info: SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:122]: #012#011[pres_uri]= sip:117093@10.16.10.99#012#011[to_user]117093#011[to_domain]= 10.16.10.99#012#011[w_user]= 117090#011[w_domain]10.16.10.99#012#011[event]= dialog#012#011[status]= active#012#011[expires]3242#012#011[callid]3119346140-8635704-1301477522967(a)10.16.10.90#011[local_cseq]=2#012#011[to_tag ]= a23c71953194c2c72e41c4d20e4f7127-7529#011[from_tag]2282475328-8635704-1301477522967#012#011[contact]sip:117090@10.16.10.90:5060#011[record_route]= SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:234]: expires 3242 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:1555]: headers:#012Max-Forwards: 70#015#012Event: dialog#015#012Contact: <sip:10.16.10.99:5060>#015#012Subscription-State: active;expires=3270#015#012Content-Type: application/dialog-info+xml#015#012 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:940]: CONTACT sip:117090@10.16.10.90:5060 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 11==11 && [10.16.10.99] =[10.16.10.99] SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5060 matches port 5060 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: presence [notify.c:1729]: ==22/6/37 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: tm [uac.c:240]: DEBUG:tm:t_uac: next_hop=<sip:117090@10.16.10.90:5060> SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: tm [uac.c:181]: DEBUG: dlg2hash: 27356 SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) SipSrv1 /usr/sbin/kamailio[26764]: INFO: presence [notify.c:1586]: NOTIFY sip:117090@10.16.10.99 via sip:117090@10.16.10.90:5060 on behalf of sip:117093@10.16.10.99 for event dialog

3 6

Suggestion dialog module / $dlg_ctx() problem.
by Alexandre Abreu 04 Apr '11

04 Apr '11

Hello. Using K 3.1.2. Before the setflag() that creates the dialog, I tried to use: $dlg_ctx(flags) = 1; Mar 30 12:29:03 devel kamailio: ERROR: dialog [dlg_var.c:165]: unknown PV name flags Mar 30 12:29:03 devel kamailio: ERROR: <core> [pvapi.c:565]: pvar "dlg_ctx" has an invalid name param [flags] Mar 30 12:29:03 devel kamailio: ERROR: <core> [pvapi.c:720]: wrong char [)/41] in [$dlg_ctx(flags)] at [14 (5)] Mar 30 12:29:03 devel kamailio: : <core> [cfg.y:3409]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 308, column 9-23: unknown script pseudo variable $dlg_ctx(flags) Right now, my goal is to add the user-agent content header ($ua) from caller/callee and list them through 'dlg_list_ctx'. I would suggest something like that: Request route: $dlg_ctx(set->ua_src) = $ua; On reply route: $dlg_ctx(set->ua_dst) = $ua; dlg_list_ctx: . ua_src:: X-Lite 3.0 build 666 ua_dst:: Linksys PAP2 . Does this suggestion make sense? Using another approach is it possible to execute this today? Thanks, Alexandre

4 11

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 March 2011