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
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!
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. *
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
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.-
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
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
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
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
