Re: [SR-Users] TEXTOPS parser problem with binary data in MIME body

[Klaus Feichtinger]

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 c

[SR-Users] Does the event_route[tm:local-request] support stateless forwarding configured in the script?

[Klaus Feichtinger]

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

[Klaus Feichtinger]

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"  hat am 10. November 2014 um 18:38
> geschrieben:
>
>
>
> On 10 Nov 2014, at 16:46, Klaus Feichtinger  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

Re: [SR-Users] header manipulation in locally generated SIP OPTIONS requests

[Klaus Feichtinger]

Hi Alex,

no - these messages are not intercepted there. I´ve already tried diverse routes
before.

Klaus

> Alex Balashov  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

[SR-Users] header manipulation in locally generated SIP OPTIONS requests

[Klaus Feichtinger]

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

[Klaus Feichtinger]

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 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: ;tag=620071678
To: 
Call-ID: 449986375
CSeq: 20 SUBSCRIBE
Contact: 
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 795715792 624699305>

SIP/2.0 202 OK
Via: SIP/2.0/TCP 10.1.1.14:5070;rport=37883;branch=z9hG4bK1540213071
From: ;tag=620071678
To: 
;tag=4f7a7e54f75c89f5b968c90011d693b5-9eed

Call-ID: 449986375
CSeq: 20 SUBSCRIBE
Expires: 1200
Contact: 
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: 
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

[Klaus Feichtinger]

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 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: ;tag=620071678
To: 
Call-ID: 449986375
CSeq: 20 SUBSCRIBE
Contact: 
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 795715792 624699305>

SIP/2.0 202 OK
Via: SIP/2.0/TCP 10.1.1.14:5070;rport=37883;branch=z9hG4bK1540213071
From: ;tag=620071678
To: 
;tag=4f7a7e54f75c89f5b968c90011d693b5-9eed

Call-ID: 449986375
CSeq: 20 SUBSCRIBE
Expires: 1200
Contact: 
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: 
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

Re: [SR-Users] UPDATE --- Can "presence" module handle publish reqs with several dialog entries? + Problem SOLUTION

[Klaus Feichtinger]

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  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; 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

[SR-Users] UPDATE --- Can "presence" module handle publish reqs with several dialog entries? + Problem SOLUTION

[Klaus Feichtinger]

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; ichildren) {
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]=#012#012  #012terminated#012#012sip:1101015004@172.31.60.13#012#012#012#012sip:117103@172.31.60.87#012#012#012#012  #012confirmed#012#012sip:117101@172.31.60.87#012#012#012#012sip:117103@172.31.60.87#012#012#012#012  #012alerting#012#012sip:1101015005@172.31.60.87#012#012#012#012sip:117103@172.31.60.87#012#012#012#012#012
May  7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence [notify.c:1564]: send_notify_request(): headers:#012Max-Forwards:
70#015#012Event: dialog#015#012Contact:
#015#012Subscription-State:
active;expires=1799#015#012Content-Type: application/dialog-info+xml#015#012
May  7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence [notify.c:926]: ps_build_dlg_t(): CONTACT = sip:116633@10.16.48.14:5070
May  7 13:11:07 sipsrvnode1 /usr/local/kamailio41/sbin/kamailio[21030]: DEBUG:
presence [

Re: [SR-Users] Can "presence" module handle publish reqs with several dialog entries?

[Klaus Feichtinger]

presence_dialoginfo [notify_body.c:84]: dlginfo_agg_nbody(): [*n_body]=#012#012  #012terminated#012#012sip:1101015004@172.31.60.13#012#012#012#012sip:117103@172.31.60.87#012#012#012#012#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:
#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




terminated

sip:1101015004@172.31.60.13



sip:117103@172.31.60.87




confirmed

sip:117101@172.31.60.87



sip:117103@172.31.60.87




a.1399360111.20480.4.0

regards,
Klaus



> Daniel-Constantin Mierla  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

Re: [SR-Users] Can "presence" module handle publish reqs with several dialog entries?

[Klaus Feichtinger]

0.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  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

[SR-Users] Can "presence" module handle publish reqs with several dialog entries?

[Klaus Feichtinger]

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] Does Kamailio not support multiple dialog elements in NOTIFY requests of the event "dialog"?

[Klaus Feichtinger]

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:



terminated

sip:1101015004@172.31.60.13



sip:117103@172.31.60.87




confirmed

sip:117101@172.31.60.87



sip:117103@172.31.60.87





(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:

#012#012terminated#012#012sip:1101015004@172.31.60.13#012#012#012#012sip:117103@172.31.60.87#012#012#012#012#012terminated#012#012sip:1101015004@172.31.60.13#012#012#012#012sip:117103@172.31.60.87#012#012#012#012#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  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;rport;branch=z9hG4bK1118069411
> >  From:  <mailto:sip:117104@172.31.60.87>
> > ;tag=4024173055-29882384-1398422652889
> >  To:  <mailto:sip:117104@172.31.60.87>
> >  Call-ID: 4044398119-29882384-1398422652889@172.31.60.54
> > <mailto: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
> > 
> >  
> >   > version="004" state="full" entity="sip:117104@172.31.60.87"
> > <mailto:sip:117104@172.31.60.87> >
> > > <mailto:4044468572-29882384-1398422652855@172.31.60.54>
> > call-id="4044468572-29882384-1398422652855@172.31.60.54"
> > <

[SR-Users] Does Kamailio not support multiple dialog elements in NOTIFY requests of the event "dialog"?

[Klaus Feichtinger]

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: ;tag=4024173055-29882384-1398422652889
To: 
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


version="004" state="full" entity="sip:117104@172.31.60.87">
  call-id="4044468572-29882384-1398422652855@172.31.60.54" 
direction="initiator">

terminated

sip:1101015004@172.31.60.13
  


  sip:117104@172.31.60.87
  

  
  call-id="2310720239-29882384-1398422648572@172.31.60.54" 
direction="initiator">

confirmed

  sip:117103@172.31.60.87
  


  sip:117104@172.31.60.87
  
   
  


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: 
Subscription-State: active;expires=1370
Content-Type: application/dialog-info+xml

version="004" state="full" entity="sip:117104@172.31.60.87">
  call-id="4044468572-29882384-1398422652855@172.31.60.54" 
direction="initiator">

terminated

sip:1101015004@172.31.60.13
  


  sip:117104@172.31.60.87
  

  


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)

[Klaus Feichtinger]

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

Re: [SR-Users] #cfgutils: sleep(x) does not work in failure_route

[Klaus Feichtinger]

Hello Daniel,

I´ve patched the code and found that the return value of the 'sleep' command is
- as expected - differing in the scenarios. For scenario 1 (no provisional
response), the return value is '0' and for scenario 2, the return value is '2'
(see log output):

scenario 1:
Nov  7 12:40:51 sipsrvnode1 kamailio33[10974]: INFO: -<|XLOG|>-:  
 s l e e p  2000ms / 2s
Nov  7 12:40:51 sipsrvnode1 kamailio33[10974]: DEBUG: cfgutils [cfgutils.c:650]:
sleep 2 seconds
Nov  7 12:40:53 sipsrvnode1 kamailio33[10974]: DEBUG: cfgutils [cfgutils.c:652]:
sleep-rc 0
Nov  7 12:40:53 sipsrvnode1 kamailio33[10974]: INFO: -<|XLOG|>-:  
 s l e p t  2000ms / 2s
scenario 2:
Nov  7 12:41:38 sipsrvnode1 kamailio33[10975]: INFO: -<|XLOG|>-:  
 s l e e p  2000ms / 2s
Nov  7 12:41:38 sipsrvnode1 kamailio33[10975]: DEBUG: cfgutils [cfgutils.c:650]:
sleep 2 seconds
Nov  7 12:41:38 sipsrvnode1 kamailio33[10975]: DEBUG: cfgutils [cfgutils.c:652]:
sleep-rc 2
Nov  7 12:41:38 sipsrvnode1 kamailio33[10975]: INFO: -<|XLOG|>-:  
 s l e p t  2000ms / 2s
This means that the sleep command is interrupted (in scenario 2) by a signal, as
the return value is representing the "number of seconds left to sleep, if the
call was interrupted by a signal handler.".

Which signal is interrupting "sleep" in this scenario (only)   :-(   ?

Klaus

> Daniel-Constantin Mierla  hat am 7. November 2013 um 10:36
> geschrieben:
> 
>  Hello,
> 
>  can you try to see if sleep_us() works?
> 
>  It is rather strange because sleep() from cfgutils just uses sleep() from
> system library, nothing special internally... sleep is interrupted by signals
> as well. Can you patch the function in kamailio to log the return code from
> sleep()?
> 
>  Cheers,
>  Daniel
> 
>  On 11/7/13 8:40 AM, klaus.lists#inode.at wrote:
> 
>  > >  Hello,
> > 
> >  I have an update:
> > 
> >  today I´ve tested with kamailio version 4.0.4, but the behaviour is
> > still the same:  it is working fine only when no response has been received;
> > as soon as a provisional response is received, the failure route is ignoring
> > the "sleep" function.
> > 
> >  Klaus
> > 
> >   > > > Hello list,
> > > 
> > >   I have troubles using the function "usleep(x)" or "sleep(x)" (the
> > > behaviour is the same) of the "cfgutils" module
> > > (
> > > ) 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|>-:   is reached for RU: ,
> > > From: , To: , Method:
> > > INVITE, Call-ID: 1107651805@10.16.48.71 
> > > 
> > >   Nov  6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO:
> > > -<|XLOG|>-:   is reached with Code: 408
> > > From: To:
> > > 
> > >   Nov  6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO:
> > > -<|XLOG|>-:  failure_route  is reached because of a
> > > BRANCH_TIMEOUT of RU:
> > > 
> > >   Nov  6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO:
> > > -<|XLOG|>-:s l e e p  2000ms / 2s
> > > 
> > >   Nov  6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO:
> > > -<|XLOG|>-:s l e p t  2000ms / 2s
> > > 
> > >   Nov  6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO:
> > > -<|XLOG|>-:   is reached for RU: ,
> > > From: , To: , Method:
> > > INVITE, Call-ID: 1107651805@10.16.48.71 
> > > 
> > >   # SC

[SR-Users] #TM: timing problem in serial forking (INVITE vs. CANCEL)

[Klaus Feichtinger]

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

[SR-Users] #cfgutils: sleep(x) does not work in failure_route

[Klaus Feichtinger]

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|>-: 
 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|>-: 
 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  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|>-:s l e e p  2000ms / 2s


Nov  6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -<|XLOG|>-: 
  s l e p t  2000ms / 2s


Nov  6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: 
-<|XLOG|>-:   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|>-: 
 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|>-:   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  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|>-:s l e e p  2000ms / 2s


Nov  6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -<|XLOG|>-: 
  s l e p t  2000ms / 2s


Nov  6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: 
-<|XLOG|>-:   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

Re: [SR-Users] TEXTOPS parser problem with binary data in MIME body

[Klaus Feichtinger]

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@:5060 SIP/2.0 Via:
> SIP/2.0/UDP :5060;branch=z9hG4bK171164E
> From: >;tag=29E16410-2541
> To: >
> Call-ID: 1DBCDACB-1B9911E3-8992FF70-D2BED293@
> Supported: timer,resource-priority,replaces,sdp-anat
> Min-SE:  90
> CSeq: 101 INVITE
> Max-Forwards: 70
> Contact: :5060>
> Expires: 1800
> P-Asserted-Identity: >
> 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 
> s=SIP Call
> c=IN IP4 
> t=0 0
> m=audio 16384 RTP/AVP 8 0
> c=IN IP4 
> 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")) {
>   

[SR-Users] TEXTOPS parser problem with binary data in MIME body

[Klaus Feichtinger]

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@:5060 SIP/2.0 Via:
SIP/2.0/UDP :5060;branch=z9hG4bK171164E
From: >;tag=29E16410-2541
To: >
Call-ID: 1DBCDACB-1B9911E3-8992FF70-D2BED293@
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE:  90
CSeq: 101 INVITE
Max-Forwards: 70
Contact: :5060>
Expires: 1800
P-Asserted-Identity: >
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 
s=SIP Call
c=IN IP4 
t=0 0
m=audio 16384 RTP/AVP 8 0
c=IN IP4 
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", "  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", "  substituting Content-Disposition
FAILED!!! \n");
   }
   msg_apply_changes();
   if (search_body("a=[a-z]+:.+[\r\n]{4}$")) {
  #!ifdef WITH_XLOGDEBUG
  xlog("L_INFO", "  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)]

[Klaus Feichtinger]

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: 

--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
<mailto:klaus.mailingli...@pernau.at>

An:

Kamailio (SER) - Users Mailing List
<mailto:sr-users@lists.sip-router.org>

Kopie (CC):

Klaus Feichtinger <mailto: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.org<mailto: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] 'subst' request for message body (SDP)

[Klaus Feichtinger]

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.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] IPv4 / v6 request to global parameter "TOS"

[Klaus Feichtinger]

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"

[Klaus Feichtinger]

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?

[Klaus Feichtinger]

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

Re: [SR-Users] Any substitute or replace function for the request-/response line of SIP messages available?

[Klaus Feichtinger]

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

[SR-Users] Any substitute or replace function for the request-/response line of SIP messages available?

[Klaus Feichtinger]

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

[Klaus Feichtinger]

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:
>>   kamailio: INFO:  [tcp_main.c:4726]: init_tcp: using
>> epoll_lt as the io watch method (auto detected)
>> /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)  /usr/sbin/kamailio[3027]:
>> ERROR:  [db.c:289]: could not add connection to the pool
>> /usr/sbin/kamailio[3027]: ERROR: lcr [lcr_mod.c:359]: unable to
>> connect to the database  /usr/sbin/kamailio[3027]: ERROR: lcr
>> [lcr_mod.c:571]: unable to open database connection
>> /usr/sbin/kamailio[3027]: ERROR:  [sr_module.c:875]: init_mod():
>> Error while initializing module lcr (/usr/lib/kamailio/modules/lcr.so)
>>   /usr/sbin/kamailio[3027]: INFO: snmpstats [snmpstats.c:387]:
>> The SNMPStats module got the kill signal  kamailio: ERROR:
>>   [daemonize.c:307]: Main process exited before writing to pipe
>>   kamailio: INFO:  [tcp_main.c:4726]: init_tcp: using
>> epoll_lt as the io watch method (auto detected)  kamailio:
>> WARNING:  [daemonize.c:352]: pid file contains old pid,
>> replacing pid  /usr/sbin/kamailio[3322]: INFO: usrloc
>> [hslot.c:53]: locks array size 512  /usr/sbin/kamailio[3322]:
>> INFO: auth
>> [auth_mod.c:312]: auth: qop set, but nonce-count (nc_enabled) support
>> disabled  /usr/sbin/kamailio[3322]: INFO: pua [pua.c:360]: the
>> query returned no result  /usr/sbin/kamailio[3322]: INFO: pike
>> [ip_tree.c:88]: probing 256 set size
>> /usr/sbin/kamailio[3322]: INFO:  [udp_server.c:178]: INFO:
>> udp_init: SO_RCVBUF is initially 111616
>> /usr/sbin/kamailio[3322]: INFO:
>> [udp_server.c:229]: INFO: udp_init: SO_RCVBUF is finally
>> 262142 /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 h

[SR-Users] Kamailio 3.1.5 core dump from the snmpstats module

[Klaus Feichtinger]

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:
 kamailio: INFO:  [tcp_main.c:4726]: init_tcp: using
epoll_lt as the io watch method (auto detected) 
/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)  /usr/sbin/kamailio[3027]:
ERROR:  [db.c:289]: could not add connection to the pool 
/usr/sbin/kamailio[3027]: ERROR: lcr [lcr_mod.c:359]: unable to connect
to the database  /usr/sbin/kamailio[3027]: ERROR: lcr
[lcr_mod.c:571]: unable to open database connection 
/usr/sbin/kamailio[3027]: ERROR:  [sr_module.c:875]: init_mod():
Error while initializing module lcr (/usr/lib/kamailio/modules/lcr.so)
 /usr/sbin/kamailio[3027]: INFO: snmpstats [snmpstats.c:387]:
The SNMPStats module got the kill signal  kamailio: ERROR:
 [daemonize.c:307]: Main process exited before writing to pipe
 kamailio: INFO:  [tcp_main.c:4726]: init_tcp: using
epoll_lt as the io watch method (auto detected)  kamailio:
WARNING:  [daemonize.c:352]: pid file contains old pid, replacing
pid  /usr/sbin/kamailio[3322]: INFO: usrloc [hslot.c:53]: locks
array size 512  /usr/sbin/kamailio[3322]: INFO: auth
[auth_mod.c:312]: auth: qop set, but nonce-count (nc_enabled) support
disabled  /usr/sbin/kamailio[3322]: INFO: pua [pua.c:360]: the
query returned no result  /usr/sbin/kamailio[3322]: INFO: pike
[ip_tree.c:88]: probing 256 set size  /usr/sbin/kamailio[3322]:
INFO:  [udp_server.c:178]: INFO: udp_init: SO_RCVBUF is initially
111616  /usr/sbin/kamailio[3322]: INFO: 
[udp_server.c:229]: INFO: udp_init: SO_RCVBUF is finally 262142 
/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:
 kamailio: INFO:  [tcp_main.c:4726]: init_tcp: using epoll_lt as the io watch method (auto detected)
 /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)
 /usr/sbin/kamailio[3027]: ERROR:  [db.c:289]: could not add connection to the pool
 /usr/sbin/kamailio[3027]: ERROR: lcr [lcr_mod.c:359]: unable to connect to the database
 /usr/sbin/kamail

Re: [SR-Users] Problem with worst case scenario of accessing 15 gateways over the DISPATCHER module - MAX_BRANCHES is reached

[Klaus Feichtinger]

> 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", "  the new value of branch counter is:
$avp(i:9) \n");
  #!endif
 } else {
  #!ifdef WITH_XLOGINFO
  xlog("L_INFO", "  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] Problem with worst case scenario of accessing 15 gateways over the DISPATCHER module - MAX_BRANCHES is reached

[Klaus Feichtinger]

> On Sunday 03 July 2011, Klaus Feichtinger wrote:
>>  I have a problem in my scenario where I use the dispatcher module for
>> (round-robin based) distribution of incoming calls to 15 (!) different
>> gateways. In idle case (= all gateways are up and running or just a
>> couple of them does not accept calls) my solution is working fine. The
>> solution is very primitive and based on the example of the dispatcher
>> module's ReadMe. However, when e.g. 12 of 15 gateways are out of
>> service (in detail: rejecting the call with "480 - Temporarily
>> Unavailable") and only the 13th would be okay, I can not reach that
>> gateway. This is because the TM module is interrupting the
>> distribution with an error message indicating that the maximum number
>> of branches (per transaction) is reached (ERROR:tm:add_uac: maximum
>> number of branches exceeded)
>>
>>  My first idea for solving this problem was/is in manipulating the
>> definition of the "max_branches" constant in the config.h file.
>> However, I prefer using the precompiled Debian packages. Therefore
>> that solution is not optimal. I have not found a method for decreasing
>> the destination_set on an easy way... Does anybody know an alternative
>> solution / workaround?
>
> Hi Klaus,
>
> did I understand it correctly, you trying sequential 15 gateways in your
>  setup? E.g.,
>
> - try GW 1
> - on error try GW 2
> - ...
> - up to GW 15?
>
> Normally I'd expect that you restrict the number of tries to something
> smaller, that you don't run into this max_branches issue and also don't
> have a  that long call setup time for the user. And I also would think
> that you would  notice that you running at a few percent of your
> capacitiy via some other  alarms, and just fix the gateways?
>
> With regards to your question, you could make the max_branches number
> configurable with a patch, at the moment its just a define.
>
> Best regards,
>
> Henning


Hi Henning,

the described scenario is not a standard scenario. This would be realistic
in emergency situations only (e.g. so many calls are coming in and the
gateways are busy => e.g. responding with "486 Busy Here" ). Also the time
delay would not be very high, because the fr_timer variable is set to a
value of 750ms before relaying the call to the dispatcher-targets
("t_set_fr([...]))") - this is just for a scenario when the target is
unreachable.

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.

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?

Thanks in advance!

Best regards,
Klaus

P.S. an excerpt of the current situation of Kamailio 3.1.4 in the scenario
- the  are representing different [failure]routes

kamailio: INFO: -<|XLOG|>-:   an incoming call to a virtual ID with
R-URI sip:225201@
kamailio: INFO: -<|XLOG|>-:   is reached for target
sip:225201@
kamailio: INFO: -<|XLOG|>-:   relay to R-URI:
sip:225201@ with DS:  and AVP: sip:10.180.38.76:5060
kamailio: INFO: -<|XLOG|>-:   is reached with Reply-Code 100
From: sip:123456@ To: sip:225201@
kamailio: INFO: -<|XLOG|>-:   is reached with Reply-Code 480
From: sip:123456@ To: sip:225201@
kamailio: INFO: -<|XLOG|>-:   is reached with Code 480 from
sip:123456@ for sip:225201@
kamailio: INFO: -<|XLOG|>-:  ds_next_dst was executed
successfully with DS  and AVP 
kamailio: INFO: -<|XLOG|>-:   is reached with Reply-Code 100
From: sip:123456@ To: sip:225201@
kamailio: INFO: -<|XLOG|>-:   is reached with Reply-Code 480
From: sip:123456@ To: sip:225201@
kamailio: INFO: -<|XLOG|>-:   is reached with Code 480 from
sip:123456@ for sip:225201@
kamailio: INFO: -<|XLOG|>-:  ds_next_dst was executed
successfully with DS  and AVP 
kamailio: INFO: -<|XLOG|>-:   is reached with Reply-Code 100
From: sip:123456@ To: sip:225201@
kamailio: INFO: -<|XLOG|>-:   is reached with Reply-Code 480
From: sip:123456@ To: sip:225201@
kamailio: INFO: -<|XLOG|>-:   is reached with Code 480 from
sip:123456@ for sip:225201@
kam

[SR-Users] Problem with worst case scenario of accessing 15 gateways over the DISPATCHER module - MAX_BRANCHES is reached

[Klaus Feichtinger]

Hi,

I have a problem in my scenario where I use the dispatcher module for
(round-robin based) distribution of incoming calls to 15 (!) different
gateways. In idle case (= all gateways are up and running or just a
couple of them does not accept calls) my solution is working fine. The
solution is very primitive and based on the example of the dispatcher
module's ReadMe. However, when e.g. 12 of 15 gateways are out of service
(in detail: rejecting the call with "480 - Temporarily Unavailable") and
only the 13th would be okay, I can not reach that gateway. This is
because the TM module is interrupting the distribution with an error
message indicating that the maximum number of branches (per transaction)
is reached (ERROR:/tm/:/add_uac/: /maximum number of branches/ exceeded)

My first idea for solving this problem was/is in manipulating the
definition of the "max_branches" constant in the config.h file. However,
I prefer using the precompiled Debian packages. Therefore that solution
is not optimal. I have not found a method for decreasing the
destination_set on an easy way... Does anybody know an alternative
solution / workaround?

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] SIP NOTIFY problem in 'presence_dialoginfo' module?

[Klaus Feichtinger]

Hello,

yes - that is true. We have changed from using the integrated pua_x
modules to publishing the information about presence and dialog_state
information by our user agents (this was recommended by Klaus, too).

The body is built by our user agents and parts of that body are
overwritten by the presence_* modul(s). E.g. the version number in the
notify messages is never identical to the version numbers of our publish
requests including the corresponding information.

However, in the meantime we have built a crazy "workaround": our version
number now ALWAYS consists of 11 digits. E.g. version '4' is inserted into
the XML body with string '004'. So the length of the placeholder
is used by our user agents, too. The result of this is: no overwriting of
the 'state="fulll"' part

But this can only be a temporary solution. Because we are always depending
on the lovely "placeholder". Whenever this will change, we have to change
the workaround, too...

br
Klaus

> Hello,
>
> you said that the publish is created by the phones in your case, not by
> kamailio with pua_dialoginfo, right?
>
> If yes, then one question for Klaus D. in this case ... the body is
> build in pua_dialoginfo with the placeholder and presence_dialoginfo
> expects that? I had not dug in the code yet, just double-checking here.
>
> Thanks,
> Daniel
>
> On 3/31/11 11:03 AM, Klaus Feichtinger wrote:
>> Hello Daniel,
>>
>> The problem is, that the format shown in the original email message
>> below isn’t 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:
>> 
>>
>> A-3) publication of a dialog state with PUBLISH:
>> 
>>
>> A-4) second notification to a dialog state change (confirmed,
>> PUBLISHed
>> with PUBLISH ad B-4 below):
>> 
>>
>>
>> Party B:
>>
>> B-1) Initial notification to a Subscribe message:
>> 
>>
>> B-2) second notification to a dialog state change (confirmed,
>> PUBLISHed
>> with PUBLISH ad A-2 above):
>> 
>>
>> B-3) third notification to a dialog state change (terminated,
>> PUBLISHed
>> with PUBLISH ad A-3 above):
>> 
>>
>> B-4) publication of a dialog state with PUBLISH:
>> 
>>
>>
>> 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: >>> version="1" ll" entity="sip:117090@10.16.10.99">   instead of
>>>> >>> 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.
>>>>
>>>>
>>&

Re: [SR-Users] SIP NOTIFY problem in 'presence_dialoginfo' module?

[Klaus Feichtinger]

Hello Daniel,

The problem is, that the format shown in the original email message below
isn’t 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:


A-3) publication of a dialog state with PUBLISH:


A-4) second notification to a dialog state change (confirmed, PUBLISHed
   with PUBLISH ad B-4 below):



Party B:

B-1) Initial notification to a Subscribe message:


B-2) second notification to a dialog state change (confirmed, PUBLISHed
   with PUBLISH ad A-2 above):


B-3) third notification to a dialog state change (terminated, PUBLISHed
   with PUBLISH ad A-3 above):


B-4) publication of a dialog state with PUBLISH:



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:
>> > ll" entity="sip:117090@10.16.10.99">  instead of
>> > 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:;tag=2453899634-24035392-1301468026894
>> To: 
>> Call-ID: 2442490492-24035392-1301468026894@10.16.10.93
>> CSeq: 20 SUBSCRIBE
>> Contact:
>> 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:
>> 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:;tag=2605346227-26329880-1301468174702
>> To: 
>> Call-ID: 2982039389-26329880-1301468174702@10.16.10.90
>> CSeq: 20 SUBSCRIBE
>> Contact:
>> 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

[SR-Users] SIP NOTIFY problem in "presence_dialoginfo" module?

[Klaus Feichtinger]

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:
 instead of
 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: ;tag=2453899634-24035392-1301468026894 To:

Call-ID: 2442490492-24035392-1301468026894@10.16.10.93
CSeq: 20 SUBSCRIBE
Contact: 
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: 
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: ;tag=2605346227-26329880-1301468174702 To:

Call-ID: 2982039389-26329880-1301468174702@10.16.10.90
CSeq: 20 SUBSCRIBE
Contact: 
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: 
Subscription-State: active;expires=3670
Content-Type: application/dialog-info+xml



  
terminated

  sip:019992116002@10.16.10.99
  


  sip:117093@10.16.10.99
  

  


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: ;tag=3644648667-26329880-1301468223499 To:

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



  
confirmed

  
  


  sip:117090@10.16.10.99
  

  



6) Status informative NOTIFY message from Kamailio (built from the
PUBLISH message above - with correct version but string overwriting!!!):
===NOTIFY
sip:117093@10.16.10.93:5060 SIP/2.0 Via: SIP/2.0/UDP
10.16.10.99;branch=z9hG4bK4cc7.faa8dc87.0
To: sip:117093@10.16.10.99;tag=2453899634-24035392-1301468026894
From: sip:117090@10.16.10.99;tag=a23c71953194c2c72e41c4d20e4f7127-86e1
CSeq: 2 NOTIFY
Call-ID: 2442490492-24035392-1301468026894@10.16.10.93
Content-Length: 592
User-Agent: kamailio (3.1.2 (i386/linux))
Max-Forwards: 70
Event: dialog
Contact: 
Subscription-State: active;expires=3570
Content-Type: application/dialog-info+xml



  
confirmed

  
  


  sip:117090@10.16.10.99
  

  




Debug information of Kamailio and information in the source code show
that the version number "000" is a placeholder only, which
should be replaced with a valid version number. However, it seems that
there is a problem in 

Re: [SR-Users] Lcr Command Disabled

[Klaus Feichtinger]

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

Re: [SR-Users] Kamailio 3.0.4: dispatcher module request

[Klaus Feichtinger]

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 :
>> 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("f

[SR-Users] Kamailio 3.0.4: dispatcher module request

[Klaus Feichtinger]

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

[SR-Users] Kamailio 3.0.4: Segfault at 4 [..] error 4 in dialog.so

[Klaus Feichtinger]

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] Failover with UCARP and Monit

[Klaus Feichtinger]

Hi,

I have built a similar solution with only one difference: I am using
HEARTBEAT instead of ucarp. In heartbeat it is possible moving
"haresources" from one active host to another. So, I activate MONIT (and
mysql + kamailio) only when the resources (e.g. virtual IP address) are
switched from one host to the other.

A sample config of heartbeat looks like:

[...]
Srv1 drbddisk::dbdata \
 Filesystem::/dev/drbd0::/mnt/drbdfiles::ext3 \
 10.0.0.1 mysql kamailio start-monit
[...]

Maybe you can use a pendant to these 'resources' in ucarp, too. I do not
know any details.

regard,
Klaus

> Hello,
> I am setting up a high-availablilty kamailio system using UCARP to
> failover between active and standby instances. To detect failure, we
> intend to use Monit.
> Monit can monitor the kamailio PID and start the process when needed
> (Example on the wiki
> http://www.kamailio.org/dokuwiki/doku.php/install:configure-initd-script)
> and  it can also do OPTIONS pings to verify it is working. If the pings
> fail  we will initiate a ucarp swap.
>
> However if the server is currently in standby, it does not have the V-IP
>  address, so I don't want to run the OPTIONS pings (I think).
>
> Does anyone use a similar system and can provide an example of how
> ucarp, monit and kamailio can work together?
>
> Many thanks,
>
> Hugh Waite
>
> ___
> 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] Changing the text of reason header in CANCEL messages

[Klaus Feichtinger]

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: "01505641636"
>> From:;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: "01505641636"
>> From:;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

[SR-Users] Changing the text of reason header in CANCEL messages

[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.

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)?

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: "01505641636"
From: ;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: "01505641636"
From: ;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

[SR-Users] Siremis 2.0: error in LCR table editing??

[Klaus Feichtinger]

Hello list,

has anybody else tried using SIREMIS 2.0 for administrating LCR tables in
kamailio 3.1.0?

I am not happy with the form / input boxes that are presented in the web
browser, because some fields are not as expected.

Following points are - from my point of view - incorrect:

 1) table "LCR_Gateway_List": the fields 'URI-scheme', 'Transport' and
'Strip' are represented by checkboxes. However, in reality these fields
are defined with smallint(3) types and e.g. transport is representing
values from NULL...4 - not boolean!

2) table "LCR_Target_List": the field priority is represented by a
checkbox, too. However, also this field is not boolean. Priorities are
represented by numbers, starting with '0' = highest priority a.s.o.


Can anybody check if this "problem" is a real one, or only present on my
PC? I have tested with IE and Firefox - the result is still the same.

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] dispatcher problem

[Klaus Feichtinger]

 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  :
>> 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.
>>