Re: [SR-Users] TEXTOPS parser problem with binary data in MIME body
Hi Frederico,
the only (quick) solution I had found was doing message parsing (MIME
body) in an external PERL script, returning the information that I was
searching for (from that body) to the config script and reducing the
multipart body to a single body. This is (until now) working fine...
However, I was using Kamailio version 3.2.x in this situation, but I
think that there will be no change to the newest version, as it is a
basic C language problem.
Please note that PERL was the language that I was finding the fastest
solution with. Maybe you can use an alternative language, too.
regards,
Klaus
Am 21.02.2015 um 01:19 schrieb Federico San Martín:
Hi Klaus, did you find a solution to this problem? I'm working with SIP-I and
having the same issue with Binary encoding. I need to encode a 0x00 value and
when the config script gets to that point, it breaks. If I encode any other hex
value it's fine. This is the config part I'm using:
route[INSERT_ACM]{
if(has_body()){
# Save the SDP body for future reference
$var(sdp_body) = $rb;
replace_body_atonce(^.+$, );
remove_hf(Content-Type);
append_hf(MIME-Version: 1.0\r\n, Content-Length);
append_hf(Content-Type: multipart/mixed;
boundary=unique-boundary-1\r\n, Allow);
replace_body_atonce(^.+$,
--unique-boundary-1\r\nContent-Disposition: signal; handling=optional\r\nContent-Type:
application/isup;
version=itu-t92+\r\n\r\n'\x06''\x02''\x04''\x01''\x29''\x01''\x01''\x00'\r\n-unique-boundary-1\r\n);
msg_apply_changes();
replace_body_all(\047, );
append_body_part($var(sdp_body),application/sdp);
}
return;
}
I tried with the escape character \0 which should be translated to ASCII hex
value '00' but it's parsed as ASCII literal values \0...
Thanks!
Federico
Federico San Martín
e-mail : fsanmar...@telecentro.net.ar
On 9/17/13 4:34 PM, Daniel wrote:
Hello,
most of the functions for pseudo-variables work with string types, that
because a script variable can have only integer or string values. Even
the length can be higher, these functions truncate at first 0. But
internally all should be kept, just not passed to config variables.
Have you tried exec_msg(), that should pass entire msg?
Otherwise, I presume there is need for some C coding to make binary
values work with variables in config.
Cheers,
Daniel
On 9/17/13 4:03 PM, Klaus Feichtinger wrote:
Hello,
I have an update to the side effects of receiving an INVITE message that
contains a MIME body with binary data:
- pseudo variables are affected, too
- the message buffer ($mb) does not include the whole message; it is
ending with the nul character
- as the message buffer does not include all data, the modification
cannot be done with an external script / program (e.g. perl, bash script)
The behaviour was tested with kamailio 4.0.3, too - no difference!
In general, the whole message is stored in a buffer, but parts of it are
inaccessible for parsing / text functions.
Any idea, what could cause this problem?
regards,
Klaus
Hello,
I have a problem with Kamailio version 3.2.4 (tested also with 3.3.5)
regarding binary data in message bodies. According RFC3261 it is
explicitly allowed using binary data within MIME bodies:
RFC 3261 section 7.4.1: SIP messages MAY contain binary bodies or body
parts. When no explicit charset parameter is provided by the sender,
media subtypes of the text type are defined to have a default charset
value of UTF-8.
However, the Kamailio function Regular Expression Transformation
(re.subst), which is based on the transformation class (exported by the
textops module) is causing problems in our customer system. In regular
scenarios, Kamailio is receiving SIP INVITE messages with a MIME body,
which is containing following parts:
- application/sdp (standard conform)
- application/x-q931 (Cisco proprietary with BINARY data!)
- application/gtd (Cisco proprietary with ASCII strings)
The content of the x-q931 and gtd body parts is depending on (UUS1)
data that were received on the ISDN line. Kamailio has to forward
User-User specific information from the ISDN line to SIP user agents (in
form of the User-to-User header field). The content of these UUS1 data
may contain also byte values 00, which is legitimate. In general,
Kamailio is in every INVITE message searching specific content in the
last body (application/gtd) and copying this content to a config
variable. As soon as the x-q931 body contains nul values (0x00 in binary
format), the parser stops at this position and cannot parse the rest of
the message. Therefore, I am missing the information that should be
copied to the SIP header field, as the parser stops before the end of
the message body!
As long as the message body does not contain 0x00, it is working fine!
My question
[SR-Users] Does the event_route[tm:local-request] support stateless forwarding configured in the script?
Hello, I´m searching for a way to keep track about success or failure of locally generated SUBSCRIBE transactions, which are typically triggered by the RLS module. In case that a subscription is rejected by the subscribee with any negative response code or the transaction is timing out, I have to trigger a specific action (e.g. sending a PUBLISH message to another user agent). This seems to be not so easy As Kamailio does not support referencing a failure_route to locally generated requests, I had the idea to forward() locally generated requests in the event_route tm:local-request to itself and handle the forwarded requests in the standard request_route, which would offer all usual options. But that seems not to be supported / allowed by Kamailio, as I have in practical tests (1) an outgoing request that is sent to the original Destination-URI (with a malformed Content-Length SIP hdr) and (2) the second request that is sent to the manual target (loop). I´ve found in the mailing list that elder Kamailio versions did not support any common way for this feature. However, can anybody give m a hint if / how this could eventually be solved with the event_route or in any alternative route? It seems that the Kamailio internally generated requests are still below the radar of TM or any other route blocks except tm:local-request. regards, Klaus ___ 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] header manipulation in locally generated SIP OPTIONS requests
Hi Alex, no - these messages are not intercepted there. I´ve already tried diverse routes before. Klaus Alex Balashov abalas...@evaristesys.com hat am 10. November 2014 um 16:47 geschrieben: On 11/10/2014 10:46 AM, Klaus Feichtinger wrote: Therefore, I´ll ask again: does kamailio offer any way for manipulating locally built SIP requests? Are these intercepted by onsend_route? -- Alex -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ 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
Re: [SR-Users] header manipulation in locally generated SIP OPTIONS requests
Thank you Olle! Your hint solved my problem and with this parameter it is working fine. It was too simple for finding it myself ;-). I´ve tried loops in the event_route, branch- and on-send route before, but without success. regards, Klaus Olle E. Johansson o...@edvina.net hat am 10. November 2014 um 18:38 geschrieben: On 10 Nov 2014, at 16:46, Klaus Feichtinger klaus.li...@inode.at wrote: Hello, does kamailio offer any possibility for adding / replacing SIP headers in locally built SIP requests? In detail: SIP OPTIONS requests that are built by the DISPATCHER module for probing the configured targets. I have to extend these messages with Accept SIP header fields (which are marked with m* in RFC3261 - so they SHOULD be present), as the dispatcher target is requiring this information for answering these requests The event_route is principally accepting the append_hf() function and is adding the configured header fields. But the answer to that request (which is including these additional header fields) is confusing the dispatcher module. Dispatcher module is reacting with this ERROR message: DEBUG: dispatcher [dispatch.c:2406]: probing set #1, URI sip:10.10.10.10 DEBUG: dispatcher [dispatch.c:2345]: OPTIONS-Request was finished with code 500 (to , group 1) ERROR: dispatcher [dispatch.c:2358]: Setting the state failed (, group 1) When I comment the textops functions out again and use the original OPTIONS messages, dispatcher is happy and knows the states of the probed targets. Therefore, I´ll ask again: does kamailio offer any way for manipulating locally built SIP requests? In some modules you can set the outbound proxy to point to yourself and then you can manipulate like any other message. /O ___ 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] header manipulation in locally generated SIP OPTIONS requests
Hello, does kamailio offer any possibility for adding / replacing SIP headers in locally built SIP requests? In detail: SIP OPTIONS requests that are built by the DISPATCHER module for probing the configured targets. I have to extend these messages with Accept SIP header fields (which are marked with m* in RFC3261 - so they SHOULD be present), as the dispatcher target is requiring this information for answering these requests The event_route is principally accepting the append_hf() function and is adding the configured header fields. But the answer to that request (which is including these additional header fields) is confusing the dispatcher module. Dispatcher module is reacting with this ERROR message: DEBUG: dispatcher [dispatch.c:2406]: probing set #1, URI sip:10.10.10.10 DEBUG: dispatcher [dispatch.c:2345]: OPTIONS-Request was finished with code 500 (to , group 1) ERROR: dispatcher [dispatch.c:2358]: Setting the state failed (, group 1) When I comment the textops functions out again and use the original OPTIONS messages, dispatcher is happy and knows the states of the probed targets. Therefore, I´ll ask again: does kamailio offer any way for manipulating locally built SIP requests? kr Klaus___ 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] Transport protocol related question - how to bind a dialog to a negotiated transport protocol
Thank you Daniel! Now its all clear and it is working fine. regards, Klaus Hello, the request within dialogs are sent to the address in the Contact header of the request/response creating the dialog. In you trace, the SUBSCRIBE has a Contact with no transport, the default one being UDP. Of course, a higher priority than Contact in sending would be Record-Route, but it is not the case of your example. In other words, SIP allows to create dialogs on one transport and request a follow up on another transport. Even the response to a request can have different destination (ip, port or protocol) than the address from where the request was sent, Via header specifying where it should be sent. Cheers, Daniel On 11/06/14 21:32, Klaus Feichtinger wrote: Hello, I wonder if it is allowed using transport protocol UDP for SIP NOTIFY requests (which are generated by Kamailio/presence module), when the SUBSCRIBE dialog was established using TCP as transport protocol. In other words: this is a principal question if it is allowed changing the transport protocol for in-dialog transactions e.g. from TCP to UDP. Initially I rather thought that in-dialog transactions shall use the same transport protocol as the dialog itself (e.g. SIP INFO requests within a standard media session), except the message would be too big for UDP, where a change to TCP is recommended. Can anybody give me a hint, if the current behaviour of Kamailio is correct or not? Or - how can I bind Kamailio to a specific transport protocol (for messages that are created by modules themselves)? Kamailio is sending NOTIFY requests with UDP, even when the subscription was done with TCP (see excerpt below). 09:58:10.360749 IP (tos 0x0, ttl 64, id 35302, offset 0, flags [DF], proto TCP (6), length 444) 10.1.1.14.37883 10.1.1.44.5060: P, cksum 0x1cb3 (correct), 1:393(392) ack 1 win 457 nop,nop,timestamp 624699305 795715664 SUBSCRIBE sip:116006@10.1.1.44;transport=TCP SIP/2.0 Via: SIP/2.0/TCP 10.1.1.14:5070;rport;branch=z9hG4bK1540213071 From: sip:1@10.1.1.14:5070;tag=620071678 To: sip:116006@10.1.1.44;transport=TCP Call-ID: 449986375 CSeq: 20 SUBSCRIBE Contact: sip:1@10.1.1.14:37883 Max-Forwards: 70 Expires: 1200 Event: presence Content-Length: 0 09:58:10.361324 IP (tos 0x10, ttl 64, id 65438, offset 0, flags [DF], proto TCP (6), length 431) 10.1.1.44.5060 10.1.1.14.37883: P, cksum 0x29fb (correct), 1:380(379) ack 393 win 215 nop,nop,timestamp 795715792 624699305 SIP/2.0 202 OK Via: SIP/2.0/TCP 10.1.1.14:5070;rport=37883;branch=z9hG4bK1540213071 From: sip:1@10.1.1.14:5070;tag=620071678 To: sip:116006@10.1.1.44;transport=TCP;tag=4f7a7e54f75c89f5b968c90011d693b5-9eed Call-ID: 449986375 CSeq: 20 SUBSCRIBE Expires: 1200 Contact: sip:10.1.1.44:5060;transport=tcp Content-Length: 0 09:58:10.361507 IP (tos 0x10, ttl 64, id 32295, offset 0, flags [none], proto UDP (17), length 484) 10.1.1.44.5060 10.1.1.14.37883: SIP, length: 456 NOTIFY sip:1@10.1.1.14:37883 SIP/2.0 Via: SIP/2.0/UDP 10.1.1.44;branch=z9hG4bKc408.509e6347.0 To: sip:1@10.1.1.14;tag=620071678 From: sip:116006@10.1.1.44;tag=4f7a7e54f75c89f5b968c90011d693b5-9eed CSeq: 2 NOTIFY Call-ID: 449986375 Content-Length: 0 User-Agent: kamailio (4.0.4 (i386/linux)) Max-Forwards: 70 Event: presence Contact: sip:10.1.1.44:5060;transport=tcp Subscription-State: active;expires=1200 Thx Klaus ___ 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 -- 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 ___ 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] Transport protocol related question - how to bind a dialog to a negotiated transport protocol
Hello, I wonder if it is allowed using transport protocol UDP for SIP NOTIFY requests (which are generated by Kamailio/presence module), when the SUBSCRIBE dialog was established using TCP as transport protocol. In other words: this is a principal question if it is allowed changing the transport protocol for in-dialog transactions e.g. from TCP to UDP. Initially I rather thought that in-dialog transactions shall use the same transport protocol as the dialog itself (e.g. SIP INFO requests within a standard media session), except the message would be too big for UDP, where a change to TCP is recommended. Can anybody give me a hint, if the current behaviour of Kamailio is correct or not? Or - how can I bind Kamailio to a specific transport protocol (for messages that are created by modules themselves)? Kamailio is sending NOTIFY requests with UDP, even when the subscription was done with TCP (see excerpt below). 09:58:10.360749 IP (tos 0x0, ttl 64, id 35302, offset 0, flags [DF], proto TCP (6), length 444) 10.1.1.14.37883 10.1.1.44.5060: P, cksum 0x1cb3 (correct), 1:393(392) ack 1 win 457 nop,nop,timestamp 624699305 795715664 SUBSCRIBE sip:116006@10.1.1.44;transport=TCP SIP/2.0 Via: SIP/2.0/TCP 10.1.1.14:5070;rport;branch=z9hG4bK1540213071 From: sip:1@10.1.1.14:5070;tag=620071678 To: sip:116006@10.1.1.44;transport=TCP Call-ID: 449986375 CSeq: 20 SUBSCRIBE Contact: sip:1@10.1.1.14:37883 Max-Forwards: 70 Expires: 1200 Event: presence Content-Length: 0 09:58:10.361324 IP (tos 0x10, ttl 64, id 65438, offset 0, flags [DF], proto TCP (6), length 431) 10.1.1.44.5060 10.1.1.14.37883: P, cksum 0x29fb (correct), 1:380(379) ack 393 win 215 nop,nop,timestamp 795715792 624699305 SIP/2.0 202 OK Via: SIP/2.0/TCP 10.1.1.14:5070;rport=37883;branch=z9hG4bK1540213071 From: sip:1@10.1.1.14:5070;tag=620071678 To: sip:116006@10.1.1.44;transport=TCP;tag=4f7a7e54f75c89f5b968c90011d693b5-9eed Call-ID: 449986375 CSeq: 20 SUBSCRIBE Expires: 1200 Contact: sip:10.1.1.44:5060;transport=tcp Content-Length: 0 09:58:10.361507 IP (tos 0x10, ttl 64, id 32295, offset 0, flags [none], proto UDP (17), length 484) 10.1.1.44.5060 10.1.1.14.37883: SIP, length: 456 NOTIFY sip:1@10.1.1.14:37883 SIP/2.0 Via: SIP/2.0/UDP 10.1.1.44;branch=z9hG4bKc408.509e6347.0 To: sip:1@10.1.1.14;tag=620071678 From: sip:116006@10.1.1.44;tag=4f7a7e54f75c89f5b968c90011d693b5-9eed CSeq: 2 NOTIFY Call-ID: 449986375 Content-Length: 0 User-Agent: kamailio (4.0.4 (i386/linux)) Max-Forwards: 70 Event: presence Contact: sip:10.1.1.44:5060;transport=tcp Subscription-State: active;expires=1200 Thx Klaus ___ 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] UPDATE --- Can presence module handle publish reqs with several dialog entries? + Problem SOLUTION
Hi Daniel,
I think we´ve found the reason, why this problem occurs!
The problem is caused in the agregate_xmls function in file notify_body.c of
the presence_dialoginfo module:
/* loop over all bodies and create the aggregated body */
for(i=0; ij; i++)
{
/* LM_DBG([n]=%d, [i]=%d, [j]=%d xml_array[i]=%p\n, n, i, j,
xml_array[j] ); */
p_root= xmlDocGetRootElement(xml_array[i]);
if(p_root ==NULL) {
LM_ERR(while geting the xml_tree root element\n);
goto error;
}
if (p_root-children) {
for (node = p_root-children; node; node = node-next) {
if (node-type == XML_ELEMENT_NODE) {
LM_DBG(node type: Element, name: %s\n, node-name);
/* we do not copy the node, but unlink it and then add it ot
the new node
* this destroys the original document but we do not need it
anyway.
* using copy instead of unlink would also copy the
namespace which
* would then be declared redundant (libxml unfortunately
can not remove
* namespaces)
*/
if (!force_single_dialog || (j==1)) {
xmlUnlinkNode(node);
if(xmlAddChild(root_node, node)== NULL) {
LM_ERR(while adding child\n);
goto error;
}
It seems to be not the best idea to unlink the XML node (=
xmlUnlinkNode(node);), as then no node-next is available any more.
Therefore, this loop will _always_ stop after one dialog entry and ignore any
additional one!
But we solved the problem in this way that the loop will not directly use
node-next, but a variable, which is set within the loop. It looks like this:
xmlNodePtr next_node = NULL;
[...]
if (p_root-children) {
for (node = p_root-children; node; node = next_node) {
next_node = node-next;
if (node-type == XML_ELEMENT_NODE) {
[...]
This solution has been tested with 2 and 3 dialog entries in a single PUBLISH
request and it is working fine. We should discuss if this is a problem that
should be solved generally or if it is a private problem in our use case.
What do you mean?
regards,
Klaus
P.S. debug output (excerpt) of the adapted src code of release 4.1.3:
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence [notify.c:744]: get_p_notify_body(): Event requires aggregation
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:75]: dlginfo_agg_nbody(): [pres_user]=116001
[pres_domain]= 10.16.48.44, [n]=1
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:127]: agregate_xmls(): [pres_user]=116001
[pres_domain]= 10.16.48.44, [n]=1
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:146]: agregate_xmls(): parsing XML body:
[n]=1, [i]=0, [j]=0 xml_array[j]=0x9311820
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:167]: agregate_xmls(): number of bodies in
total [n]=1, number of useful bodies [j]=1
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:211]: agregate_xmls(): [n]=1, [i]=0, [j]=1
xml_array[i]=0xc0c0c0c0
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:222]: agregate_xmls(): node type: Element,
name: dialog
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:222]: agregate_xmls(): node type: Element,
name: dialog
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:222]: agregate_xmls(): node type: Element,
name: dialog
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:81]: dlginfo_agg_nbody(): [n_body]=0xb7ab5274
May 7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence_dialoginfo [notify_body.c:84]: dlginfo_agg_nbody(): [*n_body]=?xml
version=1.0?#012dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info
version=000 state=full entity=sip:116001@10.16.48.44#012 dialog
id=CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13
call-id=CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13
direction=recipient#012stateterminated/state#012remote#012identitysip:1101015004@172.31.60.13/identity#012target
uri=sip:1101015004@172.31.60.13/#012/remote#012local#012identitysip:117103@172.31.60.87/identity#012target
uri=sip:117103@172.31.60.87/#012/local#012/dialog#012 dialog
id=1041054395-29684904-1398759995534@172.31.60.53
Re: [SR-Users] UPDATE --- Can presence module handle publish reqs with several dialog entries? + Problem SOLUTION
Pls find attached the patch for version 4.1.3. The three lines of code are equal
for all affected version (incl. 3.2.4, 3.3.5, 4.0.6 and 4.1.3).
regards,
Klaus
Daniel-Constantin Mierla mico...@gmail.com hat am 7. Mai 2014 um 15:45
geschrieben:
Hello,
can you send the patch to be reviewed?
Cheers,
Daniel
On 07/05/14 13:15, Klaus Feichtinger wrote:
Hi Daniel,
I think we´ve found the reason, why this problem occurs!
The problem is caused in the agregate_xmls function in file
notify_body.c of the presence_dialoginfo module:
/* loop over all bodies and create the aggregated body */
for(i=0; ij; i++)
{
/* LM_DBG([n]=%d, [i]=%d, [j]=%d xml_array[i]=%p\n, n, i, j,
xml_array[j] ); */
p_root= xmlDocGetRootElement(xml_array[i]);
if(p_root ==NULL) {
LM_ERR(while geting the xml_tree root element\n);
goto error;
}
if (p_root-children) {
for (node = p_root-children; node; node = node-next) {
if (node-type == XML_ELEMENT_NODE) {
LM_DBG(node type: Element, name: %s\n,
node-name);
/* we do not copy the node, but unlink it and then
add it ot the new node
* this destroys the original document but we do
not need it anyway.
* using copy instead of unlink would also copy
the namespace which
* would then be declared redundant (libxml
unfortunately can not remove
* namespaces)
*/
if (!force_single_dialog || (j==1)) {
xmlUnlinkNode(node);
if(xmlAddChild(root_node, node)== NULL) {
LM_ERR(while adding child\n);
goto error;
}
It seems to be not the best idea to unlink the XML node (=
xmlUnlinkNode(node);), as then no node-next is available any more.
Therefore, this loop will _always_ stop after one dialog entry and ignore
any additional one!
But we solved the problem in this way that the loop will not directly
use node-next, but a variable, which is set within the loop. It looks
like this:
xmlNodePtr next_node = NULL;
[...]
if (p_root-children) {
for (node = p_root-children; node; node = next_node) {
next_node = node-next;
if (node-type == XML_ELEMENT_NODE) {
[...]
This solution has been tested with 2 and 3 dialog entries in a single
PUBLISH request and it is working fine. We should discuss if this is a
problem that should be solved generally or if it is a private problem in
our use case.
What do you mean?
regards,
Klaus
notify_body.c.4-1-3.patch
Description: Binary data
___
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] Can presence module handle publish reqs with several dialog entries?
]: DEBUG: presence_dialoginfo [notify_body.c:166]: agregate_xmls(): number of bodies in total [n]=1, number of useful bodies [j]=1 May 6 09:09:01 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[20485]: DEBUG: presence_dialoginfo [notify_body.c:210]: agregate_xmls(): [n]=1, [i]=0, [j]=1 xml_array[i]=0xc0c0c0c0 May 6 09:09:01 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[20485]: DEBUG: presence_dialoginfo [notify_body.c:219]: agregate_xmls(): node type: Element, name: dialog May 6 09:09:01 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[20485]: DEBUG: presence_dialoginfo [notify_body.c:81]: dlginfo_agg_nbody(): [n_body]=0xb7a9d298 May 6 09:09:01 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[20485]: DEBUG: presence_dialoginfo [notify_body.c:84]: dlginfo_agg_nbody(): [*n_body]=?xml version=1.0?#012dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info version=000 state=full entity=sip:116001@10.16.48.44#012 dialog id=CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13 call-id=CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13 direction=recipient#012stateterminated/state#012remote#012identitysip:1101015004@172.31.60.13/identity#012target uri=sip:1101015004@172.31.60.13/#012/remote#012local#012identitysip:117103@172.31.60.87/identity#012target uri=sip:117103@172.31.60.87/#012/local#012/dialog#012/dialog-info#012 May 6 09:09:01 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[20485]: DEBUG: presence [notify.c:1564]: send_notify_request(): headers:#012Max-Forwards: 70#015#012Event: dialog#015#012Contact: sip:10.16.48.44:5060#015#012Subscription-State: active;expires=893#015#012Content-Type: application/dialog-info+xml#015#012 May 6 09:09:01 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[20485]: DEBUG: presence [notify.c:926]: ps_build_dlg_t(): CONTACT = sip:117711@10.16.48.14:5070 May 6 09:09:01 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[20485]: DEBUG: presence [notify.c:1574]: send_notify_request(): expires 893 status 1 May 6 09:09:01 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[20485]: DEBUG: presence [notify.c:1727]: shm_dup_cbparam(): === 22/6/37 May 6 09:09:01 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[20485]: INFO: presence [notify.c:1601]: send_notify_request(): NOTIFY sip:117711@10.16.48.14 via sip:117711@10.16.48.14:5070 on behalf of sip:116001@10.16.48.44 for event dialog May 6 09:09:01 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[20480]: DEBUG: presence [notify.c:1701]: p_tm_callback(): completed with status 200 [to_tag:4f7a7e54f75c89f5b968c90011d693b5-56dd] The DB query returned the whole body incl. 2 dialog entries, as traced with Wireshark: MySQL Query/Result, traced with Wireshark Command: Query Statement: select body,etag,sender from presentity where domain='10.16.48.44' AND username='116001' AND event='dialog' order by received_time ?xml version=1.0? dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info version=004 state=full entity=sip:117103@172.31.60.87 dialog id=CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13 call-id=CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13 direction=recipient stateterminated/state remote identitysip:1101015004@172.31.60.13/identity target uri=sip:1101015004@172.31.60.13/ /remote local identitysip:117103@172.31.60.87/identity target uri=sip:117103@172.31.60.87/ /local /dialog dialog id=1041054395-29684904-1398759995534@172.31.60.53 call-id=1041054395-29684904-1398759995534@172.31.60.53 direction=initiator stateconfirmed/state remote identitysip:117101@172.31.60.87/identity target uri=sip:117101@172.31.60.87/ /remote local identitysip:117103@172.31.60.87/identity target uri=sip:117103@172.31.60.87/ /local /dialog /dialog-info a.1399360111.20480.4.0 regards, Klaus Daniel-Constantin Mierla mico...@gmail.com hat am 5. Mai 2014 um 17:37 geschrieben: Can you try with the latest version 4.1.x? It is where I looked in the code and seemed to walk through all dialog nodes. Cheers, Daniel On 05/05/14 16:28, Klaus Feichtinger wrote: ___ 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] Can presence module handle publish reqs with several dialog entries?
Hi, during simulating scenarios in relation with the notify problem I have so far, I became unsure, if Kamilio (in principal) is supporting handling of PUBLISH requests (event dialog) that contain _more than_ one (1) dialog entry. I know that it can generate notify requests with a message body that contains more than one dialog entry. But that´s not automatically the same as handling publish requests So - is Kamailio able or not? Did anybody ever use it in such a scenario? regards, Klaus ___ 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] Can presence module handle publish reqs with several dialog entries?
[pres_uri]= sip:116001@10.16.48.44#012#011[to_user]= 116001#011[to_domain]= 10.16.48.44#012#011[w_user]= 117700#011[w_domain]= 10.16.48.14#012#011[event]= dialog#012#011[status]= active#012#011[expires]= 889#012#011[callid]= 1146821297#011[local_cseq]=1#012#011[to_tag]= 4f7a7e54f75c89f5b968c90011d693b5-8c7d#011[from_tag]= 154174339#012#011[contact]= sip:117700@10.16.48.14:5070#011[record_route]= May 5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence [notify.c:236]: expires = 889 May 5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence [notify.c:1562]: headers:#012Max-Forwards: 70#015#012Event: dialog#015#012Contact: sip:10.16.48.44:5060#015#012Subscription-State: active;expires=870#015#012Content-Type: application/dialog-info+xml#015#012 May 5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence [notify.c:964]: CONTACT = sip:117700@10.16.48.14:5070 May 5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence [notify.c:1724]: === 22/6/37 May 5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: INFO: presence [notify.c:1593]: NOTIFY sip:117700@10.16.48.14 via sip:117700@10.16.48.14:5070 on behalf of sip:116001@10.16.48.44 for event dialog May 5 16:21:49 sipsrvnode1 /usr/sbin/kamailio[23439]: DEBUG: presence [notify.c:1689]: completed with status 200 [to_tag:4f7a7e54f75c89f5b968c90011d693b5-8c7d] Main visible difference is the xml body output between PUBLISH (publish.c) and NOTIFY (notify_body.c). regards, Klaus Daniel-Constantin Mierla mico...@gmail.com hat am 5. Mai 2014 um 13:27 geschrieben: Hello, I haven't meet that case yet, but xml aggregation in presence_dialoginfo seems to walk through all children of root note for each xml doc. Maybe you can post here the output with debug=3. Cheers, Daniel On 05/05/14 13:17, Klaus Feichtinger wrote: Hi, during simulating scenarios in relation with the notify problem I have so far, I became unsure, if Kamilio (in principal) is supporting handling of PUBLISH requests (event dialog) that contain _more than_ one (1) dialog entry. I know that it can generate notify requests with a message body that contains more than one dialog entry. But that´s not automatically the same as handling publish requests So - is Kamailio able or not? Did anybody ever use it in such a scenario? regards, Klaus ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- 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] Does Kamailio not support multiple dialog elements in NOTIFY requests of the event dialog?
Hi Daniel, thx for you hint. I´m currently working on extending DBG output on several places / files. In the meantime I´ve found that the presence_dialoginfo module is still able to aggregate XML bodies. But - and that´s what I wonder about - only when the XML bodies were delivered to the server in individual PUBLISH requests with single dialog elements only. As soon as the same information is sent to the server in form of a single PUBLISH request with two dialog elements, only one element is returned to the active_watchers. Until now debug output delivered following information: (1) the DB is storing correct content of the PUBLISH request in the presentity table, which looks like this: ?xml version=1.0? dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info version=004 state=full entity=sip:117103@172.31.60.87 dialog id=CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13 call-id=CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13 direction=recipient stateterminated/state remote identitysip:1101015004@172.31.60.13/identity target uri=sip:1101015004@172.31.60.13/ /remote local identitysip:117103@172.31.60.87/identity target uri=sip:117103@172.31.60.87/ /local /dialog dialog id=1041054395-29684904-1398759995534@172.31.60.53 call-id=1041054395-29684904-1398759995534@172.31.60.53 direction=initiator stateconfirmed/state remote identitysip:117101@172.31.60.87/identity target uri=sip:117101@172.31.60.87/ /remote local identitysip:117103@172.31.60.87/identity target uri=sip:117103@172.31.60.87/ /local /dialog /dialog-info (2) according output of the DBG code line 'LM_DBG(KLAUS - body = %.*s \n, STR_FMT(body));', which is inserted before 'return body' in the 'agregate_xml' function, the return value of the agregate_xml function looks like this: dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info version=000 state=full entity=116001@10.16.48.44#012dialog id=CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13 call-id=CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13 direction=recipient#012stateterminated/state#012remote#012identitysip:1101015004@172.31.60.13/identity#012target uri=sip:1101015004@172.31.60.13/#012/remote#012local#012identitysip:117103@172.31.60.87/identity#012target uri=sip:117103@172.31.60.87/#012/local#012/dialog#012dialog id=CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13 call-id=CBE263FF-CEAE11E3-80E8CCBC-52135ACA@172.31.60.13 direction=recipient#012stateterminated/state#012remote#012identitysip:1101015004@172.31.60.13/identity#012target uri=sip:1101015004@172.31.60.13/#012/remote#012local#012identitysip:117103@172.31.60.87/identity#012target uri=sip:117103@172.31.60.87/#012/local#012/dialog#012/dialog-info#012 It seems that the first dialog element of the DB entry above is returned twice and the second dialog element is missing here! Does anybody have a hint, why the function is returning such a malformed result??? Double entries are not supported and that´s why the NOTIFY message is including only one dialog element. Thanks for any hint! br Klaus Daniel-Constantin Mierla mico...@gmail.com hat am 29. April 2014 um 21:23 geschrieben: Hello, a quick look in the code seems to use all xml nodes. Mybe you can add some debug messages in presence_dialoginfo/notify_body.c in agregate_xmls() functions and see what is not executing. Daniel On 29/04/14 20:39, Klaus Feichtinger wrote: Hi, I have a question regarding the presence + presence_dialoginfo modules of Kamailio (tested with version 3.2.x and 3.3.x). My SIP user agents are generating SIP PUBLISH requests for the event “dialog” and some of these PUBLISH requests contain multiple dialog elements in the message body. Kamailio is accepting content of these messages and storing that information in the “presentity” table of the corresponding DB. Taking a look into the presentity table is confirming that both dialog elements of the PUBLISH request are stored (as body content). However, why does the SIP NOTIFY request, which is sent to the active_watchers of this event, contain only one of these dialog entries – even that the modparam “force_single_dialog” is set to “0” or (for comparison) unset (using default value 0)? Are multiple dialog entries not / no longer supported by the Kamailio “presence_dialoginfo” module? The README of this module (through all versions incl. 4.1.x) is explaining the opposite: [...] This module by default does body aggregation. [...] e.g. if the entity has multiple dialogs the pua_dialoginfo will send multiple PUBLISH), the module will parse all the received (and still valid, depending on the Expires header in the PUBLISH request) XML documents and generate a single XML document with multiple dialog elements. [...] Exemplary content of a PUBLISH request looks like this: PUBLISH sip:117104@172.31.60.87 mailto:sip:117104@172.31.60.87 SIP/2.0 Via: SIP/2.0/UDP 172.31.60.54:5060
[SR-Users] Does Kamailio not support multiple dialog elements in NOTIFY requests of the event dialog?
Hi, I have a question regarding the presence + presence_dialoginfo modules of Kamailio (tested with version 3.2.x and 3.3.x). My SIP user agents are generating SIP PUBLISH requests for the event dialog and some of these PUBLISH requests contain multiple dialog elements in the message body. Kamailio is accepting content of these messages and storing that information in the presentity table of the corresponding DB. Taking a look into the presentity table is confirming that both dialog elements of the PUBLISH request are stored (as body content). However, why does the SIP NOTIFY request, which is sent to the active_watchers of this event, contain only one of these dialog entries -- even that the modparam force_single_dialog is set to 0 or (for comparison) unset (using default value 0)? Are multiple dialog entries not / no longer supported by the Kamailio presence_dialoginfo module? The README of this module (through all versions incl. 4.1.x) is explaining the opposite: [...] This module by default does body aggregation. [...] e.g. if the entity has multiple dialogs the pua_dialoginfo will send multiple PUBLISH), the module will parse all the received (and still valid, depending on the Expires header in the PUBLISH request) XML documents and generate a single XML document with multiple dialog elements. [...] Exemplary content of a PUBLISH request looks like this: PUBLISH sip:117104@172.31.60.87 SIP/2.0 Via: SIP/2.0/UDP 172.31.60.54:5060;rport;branch=z9hG4bK1118069411 From: sip:117104@172.31.60.87;tag=4024173055-29882384-1398422652889 To: sip:117104@172.31.60.87 Call-ID: 4044398119-29882384-1398422652889@172.31.60.54 CSeq: 21 PUBLISH Max-Forwards: 70 Content-Disposition: render;handling=required Expires: 600 Event: dialog Content-Type: application/dialog-info+xml Content-Length: 1053 ?xml version=1.0? dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info version=004 state=full entity=sip:117104@172.31.60.87 dialog id=4044468572-29882384-1398422652855@172.31.60.54 call-id=4044468572-29882384-1398422652855@172.31.60.54 direction=initiator stateterminated/state remote identitysip:1101015004@172.31.60.13/identity target uri=sip:1101015004@172.31.60.13/ /remote local identitysip:117104@172.31.60.87/identity target uri=sip:117104@172.31.60.87/ /local /dialog dialog id=2310720239-29882384-1398422648572@172.31.60.54 call-id=2310720239-29882384-1398422648572@172.31.60.54 direction=initiator stateconfirmed/state remote identitysip:117103@172.31.60.87/identity target uri=sip:117103@172.31.60.87/ /remote local identitysip:117104@172.31.60.87/identity target uri=sip:117104@172.31.60.87/ /local /dialog /dialog-info Exemplary content of the NOTIFY request looks like this: NOTIFY sip:117101@172.31.60.54:5060 SIP/2.0 Via: SIP/2.0/UDP 172.31.60.87;branch=z9hG4bKaeb3.066c77d0.0 To: sip:117101@172.31.60.87;tag=827287863-29882384-1398420840764 From: sip:117104@172.31.60.87;tag=1f98950b7b1f526eff73c08f9ffc96bd-947a CSeq: 152 NOTIFY Call-ID: 1176683682-29882384-1398420840764@172.31.60.54 Content-Length: 600 User-Agent: kamailio (3.2.4 (i386/linux)) Max-Forwards: 70 Event: dialog Contact: sip:172.31.60.87:5060 Subscription-State: active;expires=1370 Content-Type: application/dialog-info+xml dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info version=004 state=full entity=sip:117104@172.31.60.87 dialog id=4044468572-29882384-1398422652855@172.31.60.54 call-id=4044468572-29882384-1398422652855@172.31.60.54 direction=initiator stateterminated/state remote identitysip:1101015004@172.31.60.13/identity target uri=sip:1101015004@172.31.60.13/ /remote local identitysip:117104@172.31.60.87/identity target uri=sip:117104@172.31.60.87/ /local /dialog /dialog-info In other words: it is not inserting all (stored) dialog elements into the notification request. Please give me a hint, what there could be wrong.Maybe it is just a misunderstanding of the description. Br Klaus ___ 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] #TM: timing problem in serial forking (INVITE vs. CANCEL)
I think it would be nice if the CANCELs are sent before the INVITE. But this will never ensure the order how they are received at the client side. E.g. there can be packet loss which drops the CANCEL but not the INVITE, or with load balancing the INVITE can overtake the CANCEL. And if the client is not single-threaded, it may happen that the INVITE is processed before the CANCEL, although the CANCEL is received first. That´s all true. But in our scenario we have the problem that the client cannot differ between the old and new transaction, as it seems it is using the typical dialog attributes for differing transactions only. I know that this is not correct, but this problem cannot be solved so easy and fast. I suspect that the client is just buggy with transaction matching. Transactions are identified by the branch parameter in the topmost Via header. The CANCEL should have the branch parameter matching the first INVITE, and the second INVITE to the same client should have a new branch parameter. Thus, the client should be able to separate the transactions, and the INVITE can be accepted creating a second transcation. Then the CANCEL cancels the first transaction. regards Klaus Finally I found today a solution for this problem by using the ASYNC module, which I´veused for delaying the new transaction within the failure_route. It was not so easy, as the initially selected function sleep() does not work within the failure_route... regards klaus On 06.11.2013 21:16, Klaus Feichtinger wrote: Hello list, I have troubles with serial forking in kamailio 3.2.4, which is mixed with parallel forking. In the scenario that an initial INVITE message, which is addressed to sip:A, is coming in to the server, it is doing a lookup in the DB and forking (parallel) the request to e.g. 3 SIP user agents. I have set the timer to 20 seconds transaction timeout and after that timeout, the server is handling the original request in the FAILURE_ROUTE[xy]. In this failure route, the request-URI username is overwritten to an alternative one – e.g. sip:B. Then the server is doing a DB lookup again and forking the request to the number of registered user agents. A specialiy of this scenario is that it can be possible, that user agents have registered for username “A” and username “B” – in other words: they are members of the parallel forking group in serial forking step 1 and step 2. When the CANCEL and INVITE message would be sent out (to the user agents) in the correct order, then it would be no problem. But in my case the server is sending the “new” INVITE message (2^nd step in the serial forking procedure) to user agents BEFORE the CANCEL request. Therefore, these user agents are rejecting the INVITE message with “500”. Signalisation scenario == INVITE - SRV SRV - INVITE (branch-1) UA1 SRV - INVITE (branch-2) UA2 SRV - INVITE (branch-3) UA3 SRV - 180 (branch-1) UA1 SRV - 180 (branch-2) UA2 SRV - 180 (branch-3) UA3 . [timeout] SRV - CANCEL (branch-1) UA1 SRV - CANCEL (branch-2) UA2 SRV - INVITE (branch-4) UA4 SRV - INVITE (branch-5) UA5 SRV - INVITE (branch-6) UA3(!!!) SRV - CANCEL (branch-3) UA3 SRV - 500 (branch-6)UA3 It was quasi reproduceable that only the last branch of the initial transaction had that timing problem (INVITE - vs - CANCEL). My question is: why does the server send the (last) CANCEL message only after the INVITE message for some branch(es)? Could this behaviour be prohibited in any way? Thanks in advance! Klaus ___ 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] #cfgutils: sleep(x) does not work in failure_route
Hello list, I have troubles using the function usleep(x) or sleep(x) (the behaviour is the same) of the cfgutils module (http://kamailio.org/docs/modules/3.2.x/modules_k/cfgutils.html#idp76968) in the failure_route. According documentation, this function could be used in any route, including the failure_route, too. However, when I call this function, it does not show any reaction, if a transaction was already answered with a provisional response. It is still working fine, when a transaction is timing out, as no target socket is reachable. This is confusing me! Please find below some xlog messages from my configuration file in two scenarios (function |t_set_fr(2, 1); is identic in both scenarios|): (1) scenario 1 is including a primary target, looked up in the registrar DB, which is unreachable; after transaction timeout I have inserted the function sleep() in the failure_route for forcing a delay = here it is working fine (see timestamp) (2) scenario 2 is including a primary target which is responding, but not establishing the session; after transaction timeout the procedure is still the same as in scenario (1) = here is no delay visible in the log and practically detectable From my point of view, this is a malfuntion! Does anybody see it different? I´ve tested these scenarios with kamailio-3.2.x and kamailio-3.3.x - no difference. Thanks for any hints! Klaus # SCENARIO (1) ORIG TARGET IS UNREACHABLE ## Nov 6 15:58:25 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: -|XLOG|-: RELAY is reached for RU: sip:117002@10.16.48.226:5678, From: sip:110101@10.16.48.71, To: sip:115300@10.16.48.44, Method: INVITE, Call-ID: 1107651805@10.16.48.71 Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -|XLOG|-: FAILRELAY is reached with Code: 408 From: sip:110101@10.16.48.71 To: sip:115300@10.16.48.44 Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -|XLOG|-: failure_route FAILRELAY is reached because of a BRANCH_TIMEOUT of RU: sip:117002@10.16.48.226:5678 Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -|XLOG|-: FAILRELAY s l e e p 2000ms / 2s Nov 6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -|XLOG|-: FAILRELAY s l e p t 2000ms / 2s Nov 6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: -|XLOG|-: RELAYFB is reached for RU: sip:117003@10.16.48.226:7001, From: sip:110101@10.16.48.71, To: sip:115300@10.16.48.44, Method: INVITE, Call-ID: 1107651805@10.16.48.71 # SCENARIO (2) ORIG TARGET IS REACHABLE ## Nov 6 16:02:14 sipsrvnode1 /usr/sbin/kamailio[29034]: INFO: -|XLOG|-: RELAY is reached for RU: sip:117002@10.16.48.226:5678, From: sip:110101@10.16.48.71, To: sip:115300@10.16.48.44, Method: INVITE, Call-ID: 553330101@10.16.48.71 Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: FAILRELAY is reached with Code: 408 From: sip:@10.16.48.71 To: sip:4000@10.16.48.44 Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: failure_route FAILRELAY is reached because of a BRANCH_TIMEOUT of RU: sip:117002@10.16.48.44 Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: FAILRELAY s l e e p 2000ms / 2s Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: FAILRELAY s l e p t 2000ms / 2s Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -|XLOG|-: RELAYFB is reached for RU: sip:117003@10.16.48.44, From: sip:@10.16.48.71, To: sip:4000@10.16.48.44, Method: INVITE, Call-ID: 553330101@10.16.48.71 ___ 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] #TM: timing problem in serial forking (INVITE vs. CANCEL)
Hello list, I have troubles with serial forking in kamailio 3.2.4, which is mixed with parallel forking. In the scenario that an initial INVITE message, which is addressed to sip:A, is coming in to the server, it is doing a lookup in the DB and forking (parallel) the request to e.g. 3 SIP user agents. I have set the timer to 20 seconds transaction timeout and after that timeout, the server is handling the original request in the FAILURE_ROUTE[xy]. In this failure route, the request-URI username is overwritten to an alternative one -- e.g. sip:B. Then the server is doing a DB lookup again and forking the request to the number of registered user agents. A specialiy of this scenario is that it can be possible, that user agents have registered for username A and username B -- in other words: they are members of the parallel forking group in serial forking step 1 and step 2. When the CANCEL and INVITE message would be sent out (to the user agents) in the correct order, then it would be no problem. But in my case the server is sending the new INVITE message (2^nd step in the serial forking procedure) to user agents BEFORE the CANCEL request. Therefore, these user agents are rejecting the INVITE message with 500. Signalisation scenario == INVITE - SRV SRV - INVITE (branch-1) UA1 SRV - INVITE (branch-2) UA2 SRV - INVITE (branch-3) UA3 SRV - 180 (branch-1) UA1 SRV - 180 (branch-2) UA2 SRV - 180 (branch-3) UA3 . [timeout] SRV - CANCEL (branch-1) UA1 SRV - CANCEL (branch-2) UA2 SRV - INVITE (branch-4) UA4 SRV - INVITE (branch-5) UA5 SRV - INVITE (branch-6) UA3(!!!) SRV - CANCEL (branch-3) UA3 SRV - 500 (branch-6)UA3 It was quasi reproduceable that only the last branch of the initial transaction had that timing problem (INVITE - vs - CANCEL). My question is: why does the server send the (last) CANCEL message only after the INVITE message for some branch(es)? Could this behaviour be prohibited in any way? Thanks in advance! Klaus ___ 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] TEXTOPS parser problem with binary data in MIME body
Hello,
I have an update to the side effects of receiving an INVITE message that
contains a MIME body with binary data:
- pseudo variables are affected, too
- the message buffer ($mb) does not include the whole message; it is
ending with the nul character
- as the message buffer does not include all data, the modification
cannot be done with an external script / program (e.g. perl, bash script)
The behaviour was tested with kamailio 4.0.3, too - no difference!
In general, the whole message is stored in a buffer, but parts of it are
inaccessible for parsing / text functions.
Any idea, what could cause this problem?
regards,
Klaus
Hello,
I have a problem with Kamailio version 3.2.4 (tested also with 3.3.5)
regarding binary data in message bodies. According RFC3261 it is
explicitly allowed using binary data within MIME bodies:
RFC 3261 section 7.4.1: SIP messages MAY contain binary bodies or body
parts. When no explicit charset parameter is provided by the sender,
media subtypes of the text type are defined to have a default charset
value of UTF-8.
However, the Kamailio function Regular Expression Transformation
(re.subst), which is based on the transformation class (exported by the
textops module) is causing problems in our customer system. In regular
scenarios, Kamailio is receiving SIP INVITE messages with a MIME body,
which is containing following parts:
- application/sdp (standard conform)
- application/x-q931 (Cisco proprietary with BINARY data!)
- application/gtd (Cisco proprietary with ASCII strings)
The content of the x-q931 and gtd body parts is depending on (UUS1)
data that were received on the ISDN line. Kamailio has to forward
User-User specific information from the ISDN line to SIP user agents (in
form of the User-to-User header field). The content of these UUS1 data
may contain also byte values 00, which is legitimate. In general,
Kamailio is in every INVITE message searching specific content in the
last body (application/gtd) and copying this content to a config
variable. As soon as the x-q931 body contains nul values (0x00 in binary
format), the parser stops at this position and cannot parse the rest of
the message. Therefore, I am missing the information that should be
copied to the SIP header field, as the parser stops before the end of
the message body!
As long as the message body does not contain 0x00, it is working fine!
My question is:
- is this a bug in Kamailio parsing functions?
- is this a design issue of Kamailio text parsers (as binary data are
allowed acc. RFC3261) - does anybody know a solution for this problem?
This bug is causing big troubles
Thanks in advance,
Klaus Feichtinger
P.S. trace data (1)...(3) of my problem
(1) exemplary content of the x-q931 body
==Sending: Binary Message Body
Sep 13 10:50:19: Content-Type: application/x-q931
08 01 B4 05 04 03 80 90 A2 18 01 89 1E 02 82 88 6C 05 B1 35 30 30 34 70
05 B1 35 30 30 31 7D 02 91 81 7E 18 04 1D 42 75 25 92 43 31 62 94 00 00
2C 68 20 64 00 62 F2 10 41 B9 D7 BD 0D 0A
(2) SIP INVITE message (debugger view)
=INVITE sip:115101@ipv4:5060 SIP/2.0 Via:
SIP/2.0/UDP ipv4:5060;branch=z9hG4bK171164E
From: sip:1101015004@ipv4;tag=29E16410-2541
To: sip:115101@ipv4
Call-ID: 1DBCDACB-1B9911E3-8992FF70-D2BED293@ipv4
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 90
CSeq: 101 INVITE
Max-Forwards: 70
Contact: sip:1101015004@ipv4:5060
Expires: 1800
P-Asserted-Identity: sip:1101015004@ipv4
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 820
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 1770 5294 IN IP4 ipv4
s=SIP Call
c=IN IP4 ipv4
t=0 0
m=audio 16384 RTP/AVP 8 0
c=IN IP4 ipv4
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
--uniqueBoundary
Content-Type: application/x-q931
Content-Disposition: signal;handling=optional
Content-Length: 62
4 l15004p15001}~Bu%C1b..,h d.brA9W
--uniqueBoundary
Content-Type: application/gtd
Content-Disposition: signal;handling=optional
IAM,
PRN,isdn*,,,
USI,rate,c,s,c,1
USI,lay1,ulaw
TMR,00
CPN,08,,1,5001
CGN,08,,1,,,5004
UUS,3,1d42752592433162942c6820640062f21041b9d7bd
CPC,09
FCI,,,y,
GCI,185ef1291b9911e381d500270dff3fa0
--uniqueBoundary--
(3) config excerpt
if (has_body(multipart/mixed)) {
if (filter_body(application/sdp)) {
remove_hf(Mime-Version);
remove_hf(Content-Type);
append_hf(Content-Type: application/sdp\r\n);
} else {
xlog(L_WARN, route message body part 'application/sdp' not
found\n);
}
$var(UUS)=$(rb{re.subst,/^(.*)UUS,.,([a-z0-9,]*)..[A-Z][A-Z][A-Z],(.*)/\2/s});
append_hf(User-to-User: $var(UUS)\r\n, CSeq);
if
!(subst_body('/Content-Disposition..session.handling=required//s'))
{
xlog(L_WARN, route
[SR-Users] TEXTOPS parser problem with binary data in MIME body
Hello,
I have a problem with Kamailio version 3.2.4 (tested also with 3.3.5)
regarding binary data in message bodies. According RFC3261 it is
explicitly allowed using binary data within MIME bodies:
RFC 3261 section 7.4.1: SIP messages MAY contain binary bodies or body
parts. When no explicit charset parameter is provided by the sender,
media subtypes of the text type are defined to have a default charset
value of UTF-8.
However, the Kamailio function Regular Expression Transformation
(re.subst), which is based on the transformation class (exported by the
textops module) is causing problems in our customer system. In regular
scenarios, Kamailio is receiving SIP INVITE messages with a MIME body,
which is containing following parts:
- application/sdp (standard conform)
- application/x-q931 (Cisco proprietary with BINARY data!)
- application/gtd (Cisco proprietary with ASCII strings)
The content of the x-q931 and gtd body parts is depending on (UUS1)
data that were received on the ISDN line. Kamailio has to forward
User-User specific information from the ISDN line to SIP user agents (in
form of the User-to-User header field). The content of these UUS1 data
may contain also byte values 00, which is legitimate. In general,
Kamailio is in every INVITE message searching specific content in the
last body (application/gtd) and copying this content to a config
variable. As soon as the x-q931 body contains nul values (0x00 in binary
format), the parser stops at this position and cannot parse the rest of
the message. Therefore, I am missing the information that should be
copied to the SIP header field, as the parser stops before the end of
the message body!
As long as the message body does not contain 0x00, it is working fine!
My question is:
- is this a bug in Kamailio parsing functions?
- is this a design issue of Kamailio text parsers (as binary data are
allowed acc. RFC3261) - does anybody know a solution for this problem?
This bug is causing big troubles
Thanks in advance,
Klaus Feichtinger
P.S. trace data (1)...(3) of my problem
(1) exemplary content of the x-q931 body
==Sending: Binary Message Body
Sep 13 10:50:19: Content-Type: application/x-q931
08 01 B4 05 04 03 80 90 A2 18 01 89 1E 02 82 88 6C 05 B1 35 30 30 34 70
05 B1 35 30 30 31 7D 02 91 81 7E 18 04 1D 42 75 25 92 43 31 62 94 00 00
2C 68 20 64 00 62 F2 10 41 B9 D7 BD 0D 0A
(2) SIP INVITE message (debugger view)
=INVITE sip:115101@ipv4:5060 SIP/2.0 Via:
SIP/2.0/UDP ipv4:5060;branch=z9hG4bK171164E
From: sip:1101015004@ipv4;tag=29E16410-2541
To: sip:115101@ipv4
Call-ID: 1DBCDACB-1B9911E3-8992FF70-D2BED293@ipv4
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 90
CSeq: 101 INVITE
Max-Forwards: 70
Contact: sip:1101015004@ipv4:5060
Expires: 1800
P-Asserted-Identity: sip:1101015004@ipv4
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 820
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 1770 5294 IN IP4 ipv4
s=SIP Call
c=IN IP4 ipv4
t=0 0
m=audio 16384 RTP/AVP 8 0
c=IN IP4 ipv4
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
--uniqueBoundary
Content-Type: application/x-q931
Content-Disposition: signal;handling=optional
Content-Length: 62
4 l15004p15001}~Bu%C1b..,h d.brA9W
--uniqueBoundary
Content-Type: application/gtd
Content-Disposition: signal;handling=optional
IAM,
PRN,isdn*,,,
USI,rate,c,s,c,1
USI,lay1,ulaw
TMR,00
CPN,08,,1,5001
CGN,08,,1,,,5004
UUS,3,1d42752592433162942c6820640062f21041b9d7bd
CPC,09
FCI,,,y,
GCI,185ef1291b9911e381d500270dff3fa0
--uniqueBoundary--
(3) config excerpt
if (has_body(multipart/mixed)) {
if (filter_body(application/sdp)) {
remove_hf(Mime-Version);
remove_hf(Content-Type);
append_hf(Content-Type: application/sdp\r\n);
} else {
xlog(L_WARN, route message body part 'application/sdp' not
found\n);
}
$var(UUS)=$(rb{re.subst,/^(.*)UUS,.,([a-z0-9,]*)..[A-Z][A-Z][A-Z],(.*)/\2/s});
append_hf(User-to-User: $var(UUS)\r\n, CSeq);
if
!(subst_body('/Content-Disposition..session.handling=required//s'))
{
xlog(L_WARN, route substituting Content-Disposition
FAILED!!! \n);
}
msg_apply_changes();
if (search_body(a=[a-z]+:.+[\r\n]{4}$)) {
#!ifdef WITH_XLOGDEBUG
xlog(L_INFO, route double CRLF at the end of the message
body detected - is reduced to one now. \n); #!endif
$var(sdp) = $(rb{s.striptail,2});
set_body($var(sdp), application/sdp);
}
}
___
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] 'subst' request for message body (SDP)]
Hi Klaus,
Thx for your suggestion. The workaround is working fine with
Pseudo-Variable $rb instead of $mb ($var(sdp) = $(rb{s.striptail,2});)
However, the broken body is generated by Kamailio with the
filter_body() function. The server receives a multipart/mixed body and is
filtering the SDP part of it with following config (excerpt):
if (has_body(multipart/mixed)) {
if (filter_body(application/sdp)) {
remove_hf(Mime-Version);
remove_hf(Content-Type);
append_hf(Content-Type: application/sdp\r\n)
}
}
After filtering the SDP message, the message body terminates with double
CRLF, which was space between the individual parts / to the
uniqueBoundary. I tried before using subst with kamailio-like
parameters for removing the blank line:
if (subst('/(a=[a-z]+:.+)[\r\n]{4}$/\1\r\n/s')) {
and was wondering, why this does not work. The search_body() function
accepted the match pattern and so it could not be wrong at all:
if (search_body(a=[a-z]+:.+[\r\n]{4}$)) {
Should this work with Kamailio?
Regards,
Klaus
P.S. the body of the original SIP message looks as follows:
[...]
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: length
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 9550 3496 IN IP4 10.16.48.44
s=SIP Call
c=IN IP4 10.16.48.44
t=0 0
m=audio 16386 RTP/AVP 8 19
c=IN IP4 10.16.48.44
a=rtpmap:8 PCMA/8000
a=rtpmap:19 CN/8000
a=ptime:20
--uniqueBoundary
Content-Type: application/x-q931
Content-Disposition: signal;handling=optional
Content-Length: 48
0802037C052104030010231803210303
6C0C2103313730343530353335317D02
11017E0D0A2E0D0765007322143504
--uniqueBoundary
Content-Type: application/gtd
Content-Disposition: signal;handling=optional
IAM,
PRN,isdn*,,NET5*,
USI,rate,c,s,c,1
USI,lay1,alaw
TMR,00
CGN,04,,1,y,4,1704505351
UUS,0,1d427505001480418531362a640062f21001f62fbf
CPC,09
FCI,,,y,
GCI,67f9f408a73011e280056c205642ae68
--uniqueBoundary
Original-Nachricht
Betreff:
Re: [SR-Users] 'subst' request for message body (SDP)
Datum:
Fri, 05 Jul 2013 17:01:56 +0200
Von:
Klaus Darilion
klaus.mailingli...@pernau.atmailto:klaus.mailingli...@pernau.at
An:
Kamailio (SER) - Users Mailing List
sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org
Kopie (CC):
Klaus Feichtinger klaus.li...@inode.atmailto:klaus.li...@inode.at
Is this broken body generated by Kamailio, or by some other entity?
If it is done by Kamailio with filter_body(), it should be fixed.
If done by some other entity, it should be fixed in the broken entity. I
have no idea why subst does not work, but as workaround you can try
something like:
$var(sdp) = $(mb{s.striptail,2});
set_body($var(sdp), application/sdp);
regards
Klaus
On 05.07.2013 13:05, Klaus Feichtinger wrote:
Hello,
can anybody give me a hint, how I could delete the _empty_ (blank)
last
line of the message body / SDP (it consists of #012#015 only)? This
blank
line is the rest of the original MIME message, which was reduced to a
standard message with content SDP only by kamailio-3.3.4, which is
principally working fine.
I´ve tried using the textops functions subst and subst_body, but
they
do not behave as like as real SED. When I try this string manipulation
with SED, it is working fine with [sed '${/^$/d}']. But the subst
implementation does not support the additional parameters '${' / '}'.
Does anybody know how to delete the last line of the whole message?
regards,
Klaus
P.S. the end of the message looks like this:
[...]#015#012a=rtpmap:8 PCMA/8000#015#012a=ptime:20#015#012#015#012
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.orgmailto: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
Re: [SR-Users] IPv4 / v6 request to global parameter TOS
Hello Daniel, I´ve done a test with your patch now and it is working fine. IPv4 and IPv6 packets are marked with the same DSCP values (as expected) as configured with the tos parameter. Please propagate to tcp/tls and I will do a deeper test (with more scenarios) with it. It would be nice to port it back to 3.3.x (which is currently in use), too. Thanks a lot and best regards, Klaus Feichtinger Hello, there is a patch attempting to set the tos for IPv6: - http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=084be456bc0fab015cf9964ac85651fa60ea77c9 For now is only for UDP, but if it works I will propagate to tcp/tls. I tested it compiles, but had no IPv6 testbed around. If anyone can test and report back, will be appreciated. Cheers, Daniel ___ 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] IPv4 / v6 request to global parameter TOS
Hello list, in a bridging scenario with kamailio 3.3.4 and rtpproxy 1.2.1 for bridging signalling and media from an IPv4 to an IPv6 network and vice versa I found that the TOS value, which is set in kamailio.cfg, is used for IPv4 packets only. IPv6 packets have the traffic class value set to the default value 0x0. In other words: kamailio doesn´t use this variable for IPv6 packets. In the cookbook (http://www.kamailio.org/wiki/cookbooks/3.3.x/core#tos) I haven´t found any hint that it _is_ limited to IPv4 only (...for the sent IP packages). I know that the name tos may be misleading, as the original definition was outdated by dscp+ecn, but it was/is working fine now. However, as IPv6 is using dscp+ecn, too, I wonder if the tos variable should support IPv6 packets, too. Could anybody give me a hint? Is there maybe an alternative way to prioritise SIP in IPv6 with kamailio? Thanks in advance, Klaus Feichtinger ___ 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] Any substitute or replace function for the request-/response line of SIP messages available?
...I think in worst case a controlled local loop (which was helpful in other situations, too), could be a solution for fixing the UAC problem. 1. UAC (module) sending the created request to the SIP server again (loop) 2. the server is doing textops and 3. is finally forwarding the request to the real target I will try that. Klaus I know that it is an untypical way and that a B2BUA would be the best solution - that is absolutely clear. But because of a missing framework and time I decided to try it with Kamailio that I've used in many other projects, too. Textops is still used and working fine for any headers (except request line). But UAC (as you´ve recommended) didn't satisfy me. I missed a possibility for setting dialog-specific settings á la Call-ID, from-tag, to-tag and CSeq. When I´ve tried setting the CSeq header with the function $uac_req(hdrs)=CSeq: 123 INVITEr\n; it has only added a second CSeq header to the outgoing message, but didn't replace the original CSeq header that was created by the UAC module. Is there a way to influence the listed id´s, too? Klaus At the risk of sounding unhelpful, if you are having to modify the request/status line, there's probably something more deeply wrong here, and you should probably endeavour to fix the problem in a somewhat more realistic manner. Furthermore, it must be said that proxies do not make a particularly good protocol adaptor; in contrast to thicker back-to-back user agents (B2BUAs), which build out two logically independent call legs and bridge signaling events between them selectively, as they see fit, proxies are more or less obligated, in principle, to pass on what they receive, in unadulterated form. Kamailio does offer some hacks around that, in the form of textops and so on, but it doesn't really mean that it is the right tool for the job. That said, if you are dead-set on doing this, your best for regenerating a reply into a request is the 'uac' module and uac_req_send() functionality: http://kamailio.org/docs/modules/3.3.x/modules_k/uac.html#id2494432 -- Alex ___ 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] Any substitute or replace function for the request-/response line of SIP messages available?
Hi, I have a very specific situation that the implementation of a customer SIP user agent is absolutely not standards conform. Therefore, I use Kamailio as a SIP protocol adapter between the non-standard conform user agent(s) and the typical RFC3261 compliant user agents. Most conversions are working fine. But in a very specific scenario I have to change/convert a SIP response message to a SIP request message and change the SIP method´s name. This conversion is no problem for the SIP header fields. However, I haven't found a way for adapting the response-/request line of a SIP message. This line seems to be protected. The described situation of the perverse conversion I try to realize is following (please do not ask why? or think I'm mad...): (mad) UA1 == INVITE == SIP-Prot-Adapter(Kamailio) == INVITE == (typ.)UA2 UA1 == BYE == SIP-Prot-Adapter(Kamailio) == 488 == (typ.)UA2 UA1 == BYE == SIP-Prot-Adapter(Kamailio) == ACK == (typ.)UA2 I use the textops module for substitution and/or replacement in SIP header fields. But the subst and replace functions cannot be used for the request-/response line on top of the SIP messages. I was a little bit irritated, as the search function is still working on these lines, but not the subst/replace function. Creating a new SIP message with the UAC module (as alternative) is not okay, as this new message does not use the same values for Call-ID, From-tag a.s.o. and these values can't be changed before sending the message. Does anybody know a way / function / method for manipulating the request-/response line of a message? It would be perfect using a function á la sed/subst. Thanks Klaus P.S. I tested with kamailio-3.3.3 ___ 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 3.1.5 core dump from the snmpstats module
Hello Daniel, today I've tested your commit and the result was fine. No more core dumps have been created. When I did a downgrade to the official version 3.1.5 the core dumps became active again. So I can commit: your solution is working fine. Regards, Klaus Hello, I pushed a commit in master branch to deal with the case of unsuccessful startup which was the cause for this issue. The problem seemed to be some pointers which were not initialized yet, and because startup failed, the destroy function in snmstats module was called and accessed these pointers. Here is the link to commit, you can cherry pick it by hash id to 3.1 branch via git: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=06e71ad96e8f13bafac1fa5d968538f98bd08df5 I had no meanings to test it, so a report of results will be appreciated. If all goes fine, then I will backport. Cheers, Daniel On 1/31/12 4:25 PM, Klaus Feichtinger wrote: Hello list, I`ve found a negative phenomenon during startup of kamailio 3.1.x (orgininally found in version 3.1.5) that results in a core dump, triggered by the snmpstats module. During startup of the SIP proxy server machine the linux service heartbeat is responsible for starting required ressources like mysql, kamailio and snmpd. These services are monitored by the tool monit. Monit is supervising the state of the named services and if kamailio is not up and running, monit is trying to restart the service. During startup the mysql database takes some time until it is ready to use and therefore kamailio can`t connect to the database. Monit is detecting this and restarting kamailio. This is done so often until kamailio is up and running. Finally all services are up and running and the machine is working fine. However, I do not like the core dump that was created during this restart phase. As soon as the module snmpstats is not used, no core dump is created any more. Information about the core dump looks as follows: (1) output of kamailio log files: prefix kamailio: INFO:core [tcp_main.c:4726]: init_tcp: using epoll_lt as the io watch method (auto detected)prefix /usr/sbin/kamailio[3027]: ERROR: db_mysql [km_my_con.c:109]: driver error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)prefix /usr/sbin/kamailio[3027]: ERROR:core [db.c:289]: could not add connection to the poolprefix /usr/sbin/kamailio[3027]: ERROR: lcr [lcr_mod.c:359]: unable to connect to the databaseprefix /usr/sbin/kamailio[3027]: ERROR: lcr [lcr_mod.c:571]: unable to open database connectionprefix /usr/sbin/kamailio[3027]: ERROR:core [sr_module.c:875]: init_mod(): Error while initializing module lcr (/usr/lib/kamailio/modules/lcr.so) prefix /usr/sbin/kamailio[3027]: INFO: snmpstats [snmpstats.c:387]: The SNMPStats module got the kill signalprefix kamailio: ERROR: core [daemonize.c:307]: Main process exited before writing to pipe prefix kamailio: INFO:core [tcp_main.c:4726]: init_tcp: using epoll_lt as the io watch method (auto detected)prefix kamailio: WARNING:core [daemonize.c:352]: pid file contains old pid, replacing pidprefix /usr/sbin/kamailio[3322]: INFO: usrloc [hslot.c:53]: locks array size 512prefix /usr/sbin/kamailio[3322]: INFO: auth [auth_mod.c:312]: auth: qop set, but nonce-count (nc_enabled) support disabledprefix /usr/sbin/kamailio[3322]: INFO: pua [pua.c:360]: the query returned no resultprefix /usr/sbin/kamailio[3322]: INFO: pike [ip_tree.c:88]: probing 256 set sizeprefix /usr/sbin/kamailio[3322]: INFO:core [udp_server.c:178]: INFO: udp_init: SO_RCVBUF is initially 111616prefix /usr/sbin/kamailio[3322]: INFO:core [udp_server.c:229]: INFO: udp_init: SO_RCVBUF is finally 262142prefix /usr/sbin/kamailio[3329]: INFO: mi_datagram [mi_datagram.c:326]: a new child 0/3329 (2) output of GDB / core file: Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 1024 -u kamailio -g kama'. Program terminated with signal 11, Segmentation fault. [New process 3027] #0 0xb775539c in freeInterprocessBuffer () at interprocess_buffer.c:354 354 interprocess_buffer.c: No such file or directory. in interprocess_buffer.c (gdb) I know that it is not a fine method in killing kamailio during initialisation. But I have not found a better way yet. The other modules like LCR have no problem with the kill signal during initialisation. My main question is now: how could these core dumps being avoided? Did anybody have the same experience as me? Thanks in advance, Klaus ___ 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 -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
[SR-Users] Kamailio 3.1.5 core dump from the snmpstats module
Hello list, I`ve found a negative phenomenon during startup of kamailio 3.1.x (orgininally found in version 3.1.5) that results in a core dump, triggered by the snmpstats module. During startup of the SIP proxy server machine the linux service heartbeat is responsible for starting required ressources like mysql, kamailio and snmpd. These services are monitored by the tool monit. Monit is supervising the state of the named services and if kamailio is not up and running, monit is trying to restart the service. During startup the mysql database takes some time until it is ready to use and therefore kamailio can`t connect to the database. Monit is detecting this and restarting kamailio. This is done so often until kamailio is up and running. Finally all services are up and running and the machine is working fine. However, I do not like the core dump that was created during this restart phase. As soon as the module snmpstats is not used, no core dump is created any more. Information about the core dump looks as follows: (1) output of kamailio log files: prefix kamailio: INFO: core [tcp_main.c:4726]: init_tcp: using epoll_lt as the io watch method (auto detected) prefix /usr/sbin/kamailio[3027]: ERROR: db_mysql [km_my_con.c:109]: driver error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) prefix /usr/sbin/kamailio[3027]: ERROR: core [db.c:289]: could not add connection to the pool prefix /usr/sbin/kamailio[3027]: ERROR: lcr [lcr_mod.c:359]: unable to connect to the database prefix /usr/sbin/kamailio[3027]: ERROR: lcr [lcr_mod.c:571]: unable to open database connection prefix /usr/sbin/kamailio[3027]: ERROR: core [sr_module.c:875]: init_mod(): Error while initializing module lcr (/usr/lib/kamailio/modules/lcr.so) prefix /usr/sbin/kamailio[3027]: INFO: snmpstats [snmpstats.c:387]: The SNMPStats module got the kill signal prefix kamailio: ERROR: core [daemonize.c:307]: Main process exited before writing to pipe prefix kamailio: INFO: core [tcp_main.c:4726]: init_tcp: using epoll_lt as the io watch method (auto detected) prefix kamailio: WARNING: core [daemonize.c:352]: pid file contains old pid, replacing pid prefix /usr/sbin/kamailio[3322]: INFO: usrloc [hslot.c:53]: locks array size 512 prefix /usr/sbin/kamailio[3322]: INFO: auth [auth_mod.c:312]: auth: qop set, but nonce-count (nc_enabled) support disabled prefix /usr/sbin/kamailio[3322]: INFO: pua [pua.c:360]: the query returned no result prefix /usr/sbin/kamailio[3322]: INFO: pike [ip_tree.c:88]: probing 256 set size prefix /usr/sbin/kamailio[3322]: INFO: core [udp_server.c:178]: INFO: udp_init: SO_RCVBUF is initially 111616 prefix /usr/sbin/kamailio[3322]: INFO: core [udp_server.c:229]: INFO: udp_init: SO_RCVBUF is finally 262142 prefix /usr/sbin/kamailio[3329]: INFO: mi_datagram [mi_datagram.c:326]: a new child 0/3329 (2) output of GDB / core file: Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 1024 -u kamailio -g kama'. Program terminated with signal 11, Segmentation fault. [New process 3027] #0 0xb775539c in freeInterprocessBuffer () at interprocess_buffer.c:354 354 interprocess_buffer.c: No such file or directory. in interprocess_buffer.c (gdb) I know that it is not a fine method in killing kamailio during initialisation. But I have not found a better way yet. The other modules like LCR have no problem with the kill signal during initialisation. My main question is now: how could these core dumps being avoided? Did anybody have the same experience as me? Thanks in advance, Klaus Hello list, I`ve found a negative phenomenon during startup of kamailio 3.1.x (orgininally found in version 3.1.5) that results in a core dump, triggered by the snmpstats module. During startup of the SIP proxy server machine the linux service heartbeat is responsible for starting required ressources like mysql, kamailio and snmpd. These services are monitored by the tool monit. Monit is supervising the state of the named services and if kamailio is not up and running, monit is trying to restart the service. During startup the mysql database takes some time until it is ready to use and therefore kamailio can`t connect to the database. Monit is detecting this and restarting kamailio. This is done so often until kamailio is up and running. Finally all services are up and running and the machine is working fine. However, I do not like the core dump that was created during this restart phase. As soon as the module snmpstats is not used, no core dump is created any more. Information about the core dump looks as follows: (1) output of kamailio log files: prefix kamailio: INFO: core [tcp_main.c:4726]: init_tcp: using epoll_lt as the io watch method (auto detected) prefix /usr/sbin/kamailio[3027]: ERROR: db_mysql [km_my_con.c:109]: driver error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) prefix /usr/sbin/kamailio[3027]: ERROR: core [db.c:289]:
Re: [SR-Users] Problem with worst case scenario of accessing 15 gateways over the DISPATCHER module - MAX_BRANCHES is reached
Hi Klaus,
i understand.
In case that the dispatcher-target is responding with a negative
response code (as it was until now), all targets are sequentially
addressed within a time of lower than 1 second until the error message
of the TM module is interrupting that process.
1s is of course fast enough.
However, if there is no alternative to changing the define value of
MAX_BRANCHES I will use your recommendation for limiting the number of
gateways that will be addressed over the failure_route. My Question
now is: how can I count the number of branches / rejections (from the
failure_route)?
I've tried using the pseudo_variable $branch(count) (according
description of the WIKI page), but the value is 0 all the time =
not useful. I could create a private table and use the sqlops module.
Do you have any easier alternative recommendation how the number could
be limited?
What about just incrementing an variable, like an avp and check this in
an if case?
Best regards,
Henning
Hi Henning,
I decided using your recommendation with AVP. Until now I kept some
distance to this mechanism (AVP in general). But because of having no
alternative (std. $var can not work, avoidance of self compilation for a
customer project a.s.o.) I have limited the number of hits - it is now
working fine. Without any dirty hack ;-)
Thanks and best regards,
Klaus
P.S. the abstract solution
route[YZ] {
if (!ds_select_dst(1, 4)) { .. }
$avp(i:9)=1;
t_on_failure(xy);
t_on_reply(yz);
t_set_fr(3000, 750);
t_relay();
exit;
}
failure_route[xy] {
[...]
if ($avp(i:9) 10){
$avp(i:9) = $avp(i:9) + 1;
#!ifdef WITH_XLOGDEBUG
xlog(L_INFO, FAILXY the new value of branch counter is:
$avp(i:9) \n);
#!endif
} else {
#!ifdef WITH_XLOGINFO
xlog(L_INFO, FAILXY distr. was interrupted due to too many
faulty GWYs \n);
#!endif
t_reply(480, Temporarily Unavailable);
exit;
}
if (!ds_next_dst()) { .. }
[...]
}
___
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] SIP NOTIFY problem in 'presence_dialoginfo' module?
Hello Daniel, The problem is, that the format shown in the original email message below isnt original. Some space characters are deleted. I will write it in another form: Party A: A-1) initial notification to a Subscribe message was without body (because no information about the subscribed party was available) A-2) publication of a dialog state with PUBLISH: dialog-info xmlns=[..] version=4 state=full entity[..] A-3) publication of a dialog state with PUBLISH: dialog-info xmlns=[..] version=5 state=full entity[..] A-4) second notification to a dialog state change (confirmed, PUBLISHed with PUBLISH ad B-4 below): dialog-info xmlns=[..] version=1 ll entity[..] Party B: B-1) Initial notification to a Subscribe message: dialog-info xmlns=[..] version=000 state=full entity[..] B-2) second notification to a dialog state change (confirmed, PUBLISHed with PUBLISH ad A-2 above): dialog-info xmlns=[..] version=1 state=full entity[..] B-3) third notification to a dialog state change (terminated, PUBLISHed with PUBLISH ad A-3 above): dialog-info xmlns=[..] version=2 state=full entity[..] B-4) publication of a dialog state with PUBLISH: dialog-info xmlns=[..] version=4 state=full entity[..] So here you can (should) see that the full string-length of the placeholder is used all time and in the situations above filled with space characters. Regards, Klaus Hello, On 3/30/11 3:01 PM, Klaus Feichtinger wrote: 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. Is it by space or by the versios=1? Maybe the email body encoding ate the spaces, above looks like one space before 'll'. Cheers, Daniel 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@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.08e060b6.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@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@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 000): ==NOTIFY sip:117090@10.16.10.90:5060 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.99;branch=z9hG4bK10e8.31cb2284.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@10.16.10.90 Content-Length: 593 User-Agent
[SR-Users] SIP NOTIFY problem in presence_dialoginfo module?
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@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.08e060b6.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@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@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 000): ==NOTIFY sip:117090@10.16.10.90:5060 SIP/2.0 Via: SIP/2.0/UDP 10.16.10.99;branch=z9hG4bK10e8.31cb2284.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@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=000 state=full entity=117093@10.16.10.99 dialog id=3375446242-26591296-1301467877329@10.16.10.93 call-id=3375446242-26591296-1301467877329@10.16.10.93 direction=initiator stateterminated/state remote identitysip:019992116002@10.16.10.99/identity target uri=sip:019992116002@10.16.10.99/ /remote local identitysip: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@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@10.16.10.90 call-id=2769397361-26329880-1301468223108@10.16.10.90 direction=initiator stateconfirmed/state remote identitysip:116001@10.16.10.99/identity target uri=sip:116001@10.16.10.99/
Re: [SR-Users] Lcr Command Disabled
Hi, Juha - you said last year, that the kamctl-LCR-commands should be DISABLED for SR 3.1.x, because the kamctl script was not yet adapted to your new DB structure for LCR tables. http://lists.sip-router.org/pipermail/sr-dev/2010-October/009356.html http://lists.sip-router.org/pipermail/sr-dev/2010-October/009358.html AFAIK this has not yet been changed since then. Conclusion: with the current stable version you can not use LCR commands with kamctl. You have to insert DB entries manually or use SIREMIS. regards, Klaus Amit Nepal writes: I am using kamailio 3.1.2. i don't use myself kamctl. i use sip router ctl that i call myself sip-proxy_ctl and its help tells me about lcr commands. perhaps someone else is able to tell you, what this command is called by default. -- juha root@rautu:~# sip-proxy_ctl help cfg.commit cfg.diff cfg.get cfg.help cfg.list cfg.rollback cfg.set_delayed_int cfg.set_delayed_string cfg.set_now_int cfg.set_now_string core.arg core.echo core.flags core.info core.kill core.printi core.prints core.ps core.pwd core.sctp_info core.sctp_options core.shmmem core.tcp_info core.tcp_options core.udp4_raw_info core.uptime core.version ctl.connections ctl.listen ctl.who dns.add_a dns.add_ dns.add_srv dns.debug dns.debug_all dns.delete_a dns.delete_ dns.delete_all dns.delete_all_force dns.delete_cname dns.delete_ebl dns.delete_naptr dns.delete_ptr dns.delete_srv dns.delete_txt dns.lookup dns.mem_info dns.view domain.dump domain.reload dst_blacklist.add dst_blacklist.debug dst_blacklist.delete_all dst_blacklist.mem_info dst_blacklist.view htable.dump lcr.dump_gws lcr.dump_rules lcr.reload mi mi_dg mi_fifo mi_xmlrpc sl.stats system.listMethods system.methodHelp system.methodSignature tls.info tls.list tls.options tls.reload tm.cancel tm.hash_stats tm.reply tm.stats tm.t_uac_start tm.t_uac_wait ul.dump alias: ps alias: list alias: ls alias: server alias: serversion alias: who alias: listen alias: dns_mem_info alias: dns_debug alias: dns_debug_all alias: dst_blacklist_mem_info alias: dst_blacklist_debug builtin: ? builtin: help builtin: version builtin: quit builtin: exit builtin: warranty builtin: license ___ 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] Kamailio 3.0.4: dispatcher module request
Hello list,
I have a question to the dispatcher module in Kamailio version 3.0.4.
In my integration I use this module for distributing calls to a set of
gateways (with the round robin algorithm). Sometimes a gateway does not
react or send back a negative response. In that case I use the function
'ds_mark_dst(p)' in the failure_route and mark the current destination
with the flag 'probing'. I have set the threshhold value for probing mode
to '10'. This means that a gateway is effectively set to probing mode only
when it was marked with the flag 'probing' for 10 times. However,
sometimes a gateway is sending back a negative response for e.g. 5 times
and is afterwards working fine - without any problems. A few hours later
(e.g.) it is sending a negative reply again for one time. This means: the
counter for the probing_flags is increasing every time when the function
ds_mark_dst(p) is executed (in case that the process was not restarted
in the meantime!). So the problem is, that the counter is reaching the
threshhold value at any time and at that moment the gateway is set to
probing mode. Even if the gateway has sent a negative reply for only one
time (at that moment) - but according the history the proging_flag was set
several times.
What I miss in this module is a function to _reset_ that flag counter from
a REPLY_ROUTE. Note: I have to reset the counter, because the gateway does
not yet SIP OPTIONS requests and therefore it is set to 'probing' all time
until it is manually set back to active via MI command or after a process
restart. According the README file (and practical experience) the function
ds_mark_dst() is executable only within the failure_route. However, when I
want to set the flag (a) for the current destination I will do it within
a reply_route, but not in the failure_route (because I have received a
positive response and not a negative one). From my point of view it does
not make sense setting the 'active' flag for a destination from within a
FAILURE route.
Does anybody have an idea, how the 'flag-counter' could be reset (from
within the script)? I do not want to use a MI command.
configuration excerpt:
[...]
modparam(dispatcher, db_url,
mysql://openser:openserrw@localhost/openser)
modparam(dispatcher, table_name, dispatcher)
modparam(dispatcher, dst_avp, $avp(AVP_DST))
modparam(dispatcher, grp_avp, $avp(AVP_GRP))
modparam(dispatcher, cnt_avp, $avp(AVP_CNT))
modparam(dispatcher, ds_ping_from, sip:proxy@192.168.37.87)
modparam(dispatcher, ds_probing_mode, 0)
modparam(dispatcher, ds_probing_threshhold, 10)
modparam(dispatcher, ds_ping_interval, 30)
modparam(dispatcher, flags, 2)
modparam(dispatcher, force_dst, 1)
[...]
if (!ds_select_dst(1, 4)) {
sl_send_reply(404, No destination (disp));
exit;
}
t_on_failure(failureroute);
t_on_reply(replyroute);
[...]
failure_route[failureroute] {
[...]
if (t_check_status([45][08]0) || (t_branch_timeout()
!t_branch_replied())) {
ds_mark_dst(p);
if (!ds_next_dst()) {
t_reply(404, No destination (disp));
exit;
}
t_on_failure(failureroute);
t_on_reply(replyroute);
}
[...]
}
onreply_route [replyroute] {
if (t_check_status(180|200) {
# nice to have..
# ds_mark_dst(a);
}
}
Thanks in advance!
regards,
Klaus
___
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 3.0.4: dispatcher module request
thanks Carsten for your information. So I'm not the first one who wishes
this functionality :-) I'm looking forward to using this function in the
new release.
Does this mean that in Kamailio 3.0.4 no possibility is given for
automatically changing the state of a destination from 'nearly-probing' to
'active'? Could the state being changed manually only?
regards
Klaus
P.S. I think we have to speed up implementation of SIP OPTIONS support in
the gateway - this would reset the state from probing to active.
Hi Klaus,
I used to use that function especially for the purpose of resetting the
failure-counter.
We are using the ds_set_state(r) (r as reset counter) in a
onreply-route; i will check, why i never commited that patch to the
Kamailio-Repository.
I will add this functionality to git-Trunk in the next few days;
however, since it is a new feature, i will not backport it (but i can
provide patches for 3.1).
Kind regards,
Carsten
2011/2/24 Klaus Feichtinger klaus.li...@inode.at:
Hello list,
I have a question to the dispatcher module in Kamailio version 3.0.4.
In my integration I use this module for distributing calls to a set of
gateways (with the round robin algorithm). Sometimes a gateway does
not react or send back a negative response. In that case I use the
function 'ds_mark_dst(p)' in the failure_route and mark the current
destination with the flag 'probing'. I have set the threshhold value
for probing mode to '10'. This means that a gateway is effectively set
to probing mode only when it was marked with the flag 'probing' for 10
times. However, sometimes a gateway is sending back a negative
response for e.g. 5 times and is afterwards working fine - without any
problems. A few hours later (e.g.) it is sending a negative reply
again for one time. This means: the counter for the probing_flags is
increasing every time when the function ds_mark_dst(p) is executed
(in case that the process was not restarted in the meantime!). So the
problem is, that the counter is reaching the threshhold value at any
time and at that moment the gateway is set to probing mode. Even if
the gateway has sent a negative reply for only one time (at that
moment) - but according the history the proging_flag was set several
times.
What I miss in this module is a function to _reset_ that flag counter
from a REPLY_ROUTE. Note: I have to reset the counter, because the
gateway does not yet SIP OPTIONS requests and therefore it is set to
'probing' all time until it is manually set back to active via MI
command or after a process restart. According the README file (and
practical experience) the function ds_mark_dst() is executable only
within the failure_route. However, when I want to set the flag (a)
for the current destination I will do it within a reply_route, but not
in the failure_route (because I have received a positive response and
not a negative one). From my point of view it does not make sense
setting the 'active' flag for a destination from within a FAILURE
route.
Does anybody have an idea, how the 'flag-counter' could be reset (from
within the script)? I do not want to use a MI command.
configuration excerpt:
[...]
modparam(dispatcher, db_url,
mysql://openser:openserrw@localhost/openser)
modparam(dispatcher, table_name, dispatcher)
modparam(dispatcher, dst_avp, $avp(AVP_DST))
modparam(dispatcher, grp_avp, $avp(AVP_GRP))
modparam(dispatcher, cnt_avp, $avp(AVP_CNT))
modparam(dispatcher, ds_ping_from, sip:proxy@192.168.37.87)
modparam(dispatcher, ds_probing_mode, 0)
modparam(dispatcher, ds_probing_threshhold, 10)
modparam(dispatcher, ds_ping_interval, 30)
modparam(dispatcher, flags, 2)
modparam(dispatcher, force_dst, 1)
[...]
if (!ds_select_dst(1, 4)) {
sl_send_reply(404, No destination (disp));
exit;
}
t_on_failure(failureroute);
t_on_reply(replyroute);
[...]
failure_route[failureroute] {
[...]
if (t_check_status([45][08]0) || (t_branch_timeout()
!t_branch_replied())) {
ds_mark_dst(p);
if (!ds_next_dst()) {
t_reply(404, No destination (disp));
exit;
}
t_on_failure(failureroute);
t_on_reply(replyroute);
}
[...]
}
onreply_route [replyroute] {
if (t_check_status(180|200) {
# nice to have..
# ds_mark_dst(a);
}
}
Thanks in advance!
regards,
Klaus
___
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
--
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Home +49 40 34927217
Büro (Verl) +49 5246 801427
Fax +49 40 34927218
mailto:cars...@bock.info
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users
[SR-Users] Kamailio 3.0.4: Segfault at 4 [..] error 4 in dialog.so
Hello, does anybody have an idea, what this error messages could mean? Feb 16 11:23:27 SipSrvLstI1 kernel: [429767.707165] kamailio[10758]: segfault at 4 ip b78ba6e5 sp bfacece0 error 4 in dialog.so[b78a+32000] Feb 16 13:40:42 SipSrvLstI1 kernel: [438003.071797] kamailio[24880]: segfault at 4 ip b79416e5 sp bff7d460 error 4 in dialog.so[b7927000+32000] Feb 16 18:47:25 SipSrvLstI1 kernel: [456406.166885] kamailio[20939]: segfault at 4 ip b78d56e5 sp bfd821c0 error 4 in dialog.so[b78bb000+32000] I am setting the dialog flag for any incoming call. Whenever a load test is running, this error occurs. I am not sure if it is reproduceable, or not. But I think it should be, because in worst case (during a load test over night) this error was indicated in a period of 1-2 minutes. But I've found this error only yesterday, because the server was down (as a result of this error). The daemon (kamailio_3.0.4+lenny1_i386.deb) is running on a virtual machine (ESX) with OS Debian Lenny. How can I find / deliver additional info to this error / fault for analyzation? Thanks for any hints. Klaus ___ 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] Changing the text of reason header in CANCEL messages
Klaus,
thanks for your confirmation - I have tested this way and it is working
fine. Now I'm able in adapting the Reason header to a format I want to
use.
First I was not sure if this idea (spiraling) was just a mad phantasm of
mine or not. But now I'm convinced that it is a useful way :-)
regards,
Klaus
Am 16.12.2010 12:41, schrieb Klaus Feichtinger:
Hello,
I want to ask if you know any possibility in changing the text of the
SIP reason header in CANCEL requests. Is the limitation still the same
as described in the mail below from May 2010?
For my scenario I have to use the TM module, because incoming requests
from the PSTN gateway are parallelly forked to two destinations.
Whenever the pending call is cancelled by the PSTN gateway the CANCEL
request is still containing a reason header (Q.850;cause=16). But I
would like to adapt the text of this header according RFC3326 (e.g.
'Reason: SIP ;cause=487 ;text=Request Terminated'). The feature
e2e-cancel-reason is working fine - the original text is copied, but
no textops function can make any change.
What about changing the gateway to send the Reason header you want?
Is there any trick possible to change the text of this header before
it is handled by the proxy (e.g. in creating a spirale - change the
text and forward it to the same proxy again)?
You should be able to do it as you said - by stateless [1] spiraling the
call (INVITE+...+CANCEL) one time and modify the Reason header of the
CANCEL request using textops. (by using stateless forwarding the CANCEL
is not hop-by-hop but forwarded too).
http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#forward
Klaus
Or in worst case if this is currently absolutely impossible - would
this be an acceptable request for a new feature in any upcoming
release of Kamailio 3.1.x? In the release 3.1.x it is still possible
to store the text of an incoming reason header, so I guess it could be
no problem in overwriting this text with any function.. Is anybody
else interested in this feature?
regards,
Klaus
++
Am 21.05.2010 09:26, schrieb François BERGANZ:
When I use forward, it doesnt work!
I don't know how to do
It works fine for me:
route{
if (is_method(CANCEL)) {
if (!is_present_hf(Reason)) {
xlog(L_ERR, reason missing);
append_hf(Reason: Q.850; cause=31\r\n);
xlog(L_ERR, Reason added);
}
forward();
exit;
}
Note: above code snippet only works if the proxy does not do any
parallel forking of the INVITE. It may also be necessary to change the
request-URI to forward the request to the same destination as the
INVITE.
in:
U 2010/05/21 10:29:38.372934 83.136.33.3:16534 - 88.198.53.113:5060
CANCEL sip:01505641...@83.123.45.165 SIP/2.0
Via: SIP/2.0/UDP
10.10.0.51:16534;branch=z9hG4bK-d8754z-7b591160b17cfc57-1---d8754z-;rport
To: 01505641636sip:01505641...@83.123.45.165
From:sip:kl...@83.123.45.165;tag=7c681960
Call-ID: MzcxYTgzZmIwMGYyMTA4YzVkN2IzZDhjYjhjYjYwNTk.
CSeq: 2 CANCEL
User-Agent: eyeBeam release 1102q stamp 51814
Content-Length: 0
out:
U 2010/05/21 10:29:38.373331 88.198.53.113:5060 - 83.123.45.165:5060
CANCEL sip:01505641...@83.123.45.165 SIP/2.0
Via: SIP/2.0/UDP
88.198.53.113;branch=z9hG4bK-d8754z-7b591160b17cfc57-1---d8754z- Via:
SIP/2.0/UDP
10.10.0.51:16534;received=83.136.33.3;branch=z9hG4bK-d8754z-7b591160b17cfc57-1---d8754z-;rport=16534
To: 01505641636sip:01505641...@83.123.45.165
From:sip:kl...@83.123.45.165;tag=7c681960
Call-ID: MzcxYTgzZmIwMGYyMTA4YzVkN2IzZDhjYjhjYjYwNTk.
CSeq: 2 CANCEL
User-Agent: eyeBeam release 1102q stamp 51814
Content-Length: 0
Reason: Q.850; cause=31
regards
Klaus
___
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
Re: [SR-Users] dispatcher problem
Carsten, thanks for your clarification. I guessed that it was influenced by the retransmission of the OPTIONS request. But I hoped this check-health mechanism would not be based on the standard mechanism. Because with this behaviour I do not understand what the former default interval of 10 seconds should bring? The default timeout for the request is 30 seconds and the check-health interval is 10 seconds. So in every period the server has to handle 3 requests to one and the same target in parallel... This does - from my point of view - not make sense. Therefore I have set the ping_interval to a value of 60 seconds and can now live with the retransmission (without interference). regards Klaus Hi, what you are seeing here, are the retransmits for the OPTIONS-Requests. The Dispatcher checks every 10 seconds for dead destinations and then sends out the OTIONS-Request using TM (which is doing the retransmits). This might be a little overlapping, e.g. - OPTIONS-Request (initial request, 1st try) - 0,5s (retransmit, 1st try) - 1s (retransmit, 1st try) - 2s (retransmit, 1st try) = 3,5 Seconds from initial request - 4s (retransmit, 1st try) = 7,5 Seconds from initial request - 10s OPTIONS-Request (initial request, 2nd try) - 10,5s (retransmit, 2nd try) - 11,5s (2x, retransmit, 2nd try + retransmit, 1st try) - 13,5s (retransmit, 2nd try) - 15,5s (retransmit, 1st try) (and so on). That is the reason for this behaviour, and may look confusing Carsten 2010/9/10 klaus.li...@inode.at: Hello Daniel, these days I'm playing a lot with the dispatcher module and from my point of view I found a strange behaviour of the module, which is not according the description in the documentation and as you've explained in the list. I've learned that polling of failed gwys is only supported when the parameter ds_ping_interval is set to a value above '0' (the default value of '10' is no longer supported). However, when a gateway is in probing state the polling interval is never the value that is set in the modparam, it is - in dependent from this value - always a 'fix' period. E.g. the OPTIONS message is sent in following interval: 0.5-1-2-4-4-4-4 and afterwards it looks a little bit chaotic without a specified interval (= random). Is this as expected or do I miss another modparam that is mandatory? My config looks as follows: # - DISPATCHER - modparam(dispatcher, db_url, mysql://openser:opense...@localhost/openser) modparam(dispatcher, table_name, dispatcher) modparam(dispatcher, dst_avp, $avp(AVP_DST)) modparam(dispatcher, grp_avp, $avp(AVP_GRP)) modparam(dispatcher, cnt_avp, $avp(AVP_CNT)) modparam(dispatcher, ds_ping_from, sip:pr...@192.168.37.87) modparam(dispatcher, ds_probing_mode, 0) modparam(dispatcher, ds_ping_interval, 20) modparam(dispatcher, flags, 2) modparam(dispatcher, force_dst, 1) regards, Klaus Feichtinger Hello, I fixed, thanks for pointing out. We would need a documentation marshall that should update the docs as something related is discussed on the lists. But none really volunteered to do it. For developers is not always obvious or easy (due to lack of time) to track the doc changes. Anyone stepping forward? Cheers, Daniel On 9/8/10 12:01 PM, klaus.li...@inode.at wrote: Klaus, Daniel-Constantin, I had the same problem and found the 'solution' in archived mails from diverse mailing lists only. In general the documentation is not really up-to-date. Because also the hint in modules documentation, chapter 3.16 [...] if compiled with the probing of failed gateways enabled [...] is no longer valid (as commented by Daniel-Constantin in another list). Please update the documentation for the next major release 3.1 to avoid any more confusions. THX regards, Klaus Am 07.09.2010 20:58, schrieb Daniel-Constantin Mierla: Hello, you have to set the ping interval parameter: http://kamailio.org/docs/modules/stable/modules_k/dispatcher.html#id2590104 I see that documentation says its default value is 10, but in sources is 0, which means this feature is disabled. That was the reason I didn't configured it. Thanks Klaus ___ 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 -- Daniel-Constantin Mierla http://www.asipto.com ___ 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
