Hello,
I think it is time to prepare for first minor release (3.0.1) in 3.0
series. We are approaching two months since kamailio 3.0.0, period
within several issues were reported and fixed. Please report anything
you are aware is not currently working in 3.0 to
sr-dev(a)lists.sip-router.org or bug tracker:
http://sip-router.org/tracker/
As for date, end of this week or beginning of next week would be a good
time? Other opinions?
Cheers,
Daniel
--
Daniel-Constantin Mierla
Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
* http://www.asipto.com/index.php/sip-router-masterclass/
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Ronald Voermans (voermans)
Attached to Project - sip-router
Summary - display name without quotes and uac_replace_from
Task Type - Bug Report
Category - Core
Status - Assigned
Assigned To - Andrei Pelinescu-Onciul
Operating System - All
Severity - Medium
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - With Kamailio 3.0.0 the uac_replace_from isn't working correctly. When a From-display-name doesn't have quotes and has spaces in it, the function uac_replace_from only replaces the first word of the display name instead of the full display name. When the display name is enclosed by quotes, this issue doesn't occur.
The bug seems to be exposed in parser_to.c.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=39
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#39 - display name without quotes and uac_replace_from
User who did this - Ronald Voermans (voermans)
http://sip-router.org/tracker/index.php?do=details&task_id=39
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Module: sip-router
Branch: master
Commit: afd800bd67c3dd54db69a5c24e0a8bd362609061
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=afd800b…
Author: Jan Janak <jan(a)ryngle.com>
Committer: Jan Janak <jan(a)ryngle.com>
Date: Tue Mar 2 16:03:42 2010 -0500
parse_param: Let the body point behind '=' when body is missing.
This fixes potential issues with functions that copy parameters
structures from private to shared memory because such functions
usually translate string pointers using a base pointing at the
first character of the parameter list.
Reported by Daniel.
---
parser/parse_param.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/parser/parse_param.c b/parser/parse_param.c
index f86d1c9..c68e237 100644
--- a/parser/parse_param.c
+++ b/parser/parse_param.c
@@ -456,9 +456,8 @@ inline int parse_param(str *_s, pclass_t _c, param_hooks_t *_h, param_t *t)
if (_s->len == 0) {
/* Be forgiving and accept parameters with missing value,
- * we just set the body of such a parameter to an empty
- * string. */
- t->body.s = "";
+ * we just set the length of parameter body to 0. */
+ t->body.s = _s->s;
t->body.len = 0;
} else if (parse_param_body(_s, t) < 0) {
LOG(L_ERR, "parse_params(): Error while parsing param body\n");
Module: sip-router
Branch: master
Commit: a3b2fcde99ebd5f625d0168473caef5dbbaf1029
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a3b2fcd…
Author: Jan Janak <jan(a)ryngle.com>
Committer: Jan Janak <jan(a)ryngle.com>
Date: Tue Feb 23 14:38:31 2010 -0500
param_parser: Accept parameters with missing bodies.
This change makes the parameter parser more forgiving. It accepts
parameters with missing bodies (foo=), such parameters will have
the body set to an empty string. Observed on iptel.org
---
parser/parse_param.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/parser/parse_param.c b/parser/parse_param.c
index 8dee261..f86d1c9 100644
--- a/parser/parse_param.c
+++ b/parser/parse_param.c
@@ -455,11 +455,12 @@ inline int parse_param(str *_s, pclass_t _c, param_hooks_t *_h, param_t *t)
trim_leading(_s);
if (_s->len == 0) {
- LOG(L_ERR, "parse_params(): Body missing\n");
- goto error;
- }
-
- if (parse_param_body(_s, t) < 0) {
+ /* Be forgiving and accept parameters with missing value,
+ * we just set the body of such a parameter to an empty
+ * string. */
+ t->body.s = "";
+ t->body.len = 0;
+ } else if (parse_param_body(_s, t) < 0) {
LOG(L_ERR, "parse_params(): Error while parsing param body\n");
goto error;
}
Hi
My issue is how to construct ACK correctly in the dialog in case of
NATed client. ( please see
http://lists.sip-router.org/pipermail/sr-dev/2010-February/006145.html
for the scenario detail )
nated-u1(bob)---> P1 --> nated-u2 (alice)
e.g: bob calls alcie,
(A) In the normal case,
U1 ---> P1 ---> U2
Invite->
<--200 OK
ACK -->
The good ACK msg capted from P1 to U2 is:
#
U 67.154.255.47:4060 (P1) -> 67.154.250.3:2051 ( public ip/port for U2)
ACK sip:alice@172.16.8.42:2051;line=e96ci3a9 SIP/2.0.
(B) In the abormal case,
U1 ---> P1 ---> U2
Invite->
ACK -->
BYE -->
<--488
P1 check something and need to send ACK/BYE to u2
The pseudo code try to use dialog module function:
dialog.request_inside(&method_ACK,&reqbuf,NULL, d,cb,cbp)
>From the log file:
DEBUG:tm:t_uac: next_hop=<sip:alice@centercall.net>
The captured ACK msg:
U 67.154.255.47:4060 (P1) -> 67.154.255.44:5060 (i-cscf)
ACK sip:alice@centercall.net SIP/2.0.
The two ACK msg is different.
Questions:
(1) How can I generate the correct ACK msg in this case?
(2) The issue with second ACK need more explaination ( from openims
point of view):
i-cscf ---- s-cscf
|
U1 --> P1 --> U2
(i/s-cscf is sip proxy)
With this kind of ACK, the ACK first goes to i-cscf, which choose
s-cscf, then goes back to P1, P1 will try to relay the ACK
route[Term_Subsequent]{
...
if (!P_security_relay())
P_NAT_relay();
t_relay()
...
}
The log shows:
22106 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: tm
[t_funcs.c:184]: tm: put_on_wait: transaction 0xb59834b4 already on wait
It seems the tm module put this new ACK (the P1-generated ACK loop back
to P1 now ) on hold, NOT relaying to U2.
>From sniffed packets, the ACK never reaches the U2.
Any good way to resolve the issue?
Just FYI the BYE can reach U2 as it is a new tm transaction.
#
U 67.154.255.47:4060 -> 67.154.255.44:5060
BYE sip:alice@centercall.net SIP/2.0.
22512 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: tm
[t_lookup.c:711]: DEBUG: t_lookup_request: no transaction found
22558 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: tm
[t_funcs.c:388]: SER: new transaction fwd'ed
/////////detailed log for ACK in Term_Subsequent ///////////////
21997 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: <core>
[parser/msg_parser.c:627]: SIP Request:
21998 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: <core>
[parser/msg_parser.c:629]: method: <ACK>
21999 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: <core>
[parser/msg_parser.c:631]: uri: <sip:alice@172.16.8.42
:2051;line=otkb9mdz>
22000 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: <core>
[parser/msg_parser.c:633]: version: <SIP/2.0>
22091 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: NOTICE: <script>: >>
Term_Subsequent before relay
22092 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: <core>
[mem/q_malloc.c:366]: qm_malloc(0x8272e60, 36) called from pcscf:
registration.c: P_security_relay(1086)
22093 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: <core>
[mem/q_malloc.c:406]: qm_malloc(0x8272e60, 36) returns address
0x82e2140 frag. 0x82e2128 (size=36) on 1 -th hit
22094 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: pcscf
[registration.c:1104]: ERR:P-CSCF:P_security_relay: we cannot find the
contact or its IPSec/TLS SAs for <0://172.16.8.42:2051>.
22095 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: <core>
[mem/q_malloc.c:428]: qm_free(0x8272e60, 0x82e2140), called from pcscf:
registration.c: P_security_relay(1107)
22096 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: <core>
[mem/q_malloc.c:450]: qm_free: freeing frag. 0x82e2128 alloc'ed from
pcscf: registration.c: P_security_relay(1086)
22097 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: <core>
[mem/q_malloc.c:366]: qm_malloc(0x8272e60, 41) called from pcscf:
registration.c: get_NAT_dst_uri(921)
22098 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: <core>
[mem/q_malloc.c:406]: qm_malloc(0x8272e60, 44) returns address
0x830605c frag. 0x8306044 (size=52) on 1 -th hit
22099 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: INFO: pcscf
[registration.c:1031]: INFO:P-CSCF:P_NAT_relay: <sip:67.154.250.3:2051>
22100 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: tm
[t_lookup.c:1387]: DEBUG: t_newtran: msg id=77 , global msg id=76 , T on
entrance=0xffffffff
22101 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: tm
[t_lookup.c:528]: t_lookup_request: start searching: hash=37128, isACK=1
22102 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: tm
[t_lookup.c:470]: DEBUG: RFC3261 transaction matched,
tid=8019.82c67232.0
22103 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: tm
[t_lookup.c:728]: DEBUG: t_lookup_request: transaction found (T
=0xb59834b4)
22104 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: tm
[t_reply.c:1420]: DEBUG: cleanup_uac_timers: RETR/FR timers reset
22105 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: <core>
[timer.c:595]: timer_add called on an active timer 0xb59834fc
(0xb5842c2c, 0xb5842c2c), flags 201
22106 Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: DEBUG: tm
[t_funcs.c:184]: tm: put_on_wait: transaction 0xb59834b4 already on wait
Mar 2 11:06:25 im1 /usr/sbin/ser[27551]: NOTICE: <script>: >>
Term_Subsequent end
Kind Regards
Min Wang
.
Hi
I have following scenario:
u1---> p1 --> u2
u1 calling u2, u2 reply with 200 OK,
The p1 need to check something, and decide to send ACK/Bye to u2,
and 488 to u1:
onreply_route[1]
{
if (my_function_check("")) {
release_call_onreply("");
}
}
The question is : How to do implement release_call_onreply correctly?
The pseudo codes is like:
t=tmb.t_gett();
send_request(method_ACK);
send_request(method_BYE);
reason_code = 488
tmb.t_reply(t->uas.request,reason_code,reason_text);
(Not sure if t_reply can be called here or not.)
The ACK/Bye is sent to U2, 488 is sent to U1,
But the issue is it seems the original 200 OK is forwarded to U1 as
well.
How to avoid it?
Or should the Data lumps function be used here to modify the 200 reply
msg instead of using t_reply here?
Kind Regards
Min Wang