sr-dev March 2010

sr-dev@lists.kamailio.org

24 participants
359 discussions

[tracker] Task opened: display name without quotes and uac_replace_from
by sip-router 02 Mar '10

02 Mar '10

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.

1 0

[tracker] Assignee added: display name without quotes and uac_replace_from
by sip-router 02 Mar '10

02 Mar '10

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.

1 0

git:master: parse_param: Let the body point behind '=' when body is missing .
by Jan Janak 02 Mar '10

02 Mar '10

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

1 0

git:master: param_parser: Accept parameters with missing bodies.
by Jan Janak 02 Mar '10

02 Mar '10

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

2 2

How to contruct ACK/BYE correctly in dialog with NATed client
by Min Wang 02 Mar '10

02 Mar '10

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 .

1 0

How to change the reply msg in the onreply_route
by Min Wang 02 Mar '10

02 Mar '10

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

3 10

git:master: core: added missing parsed flags & minor get_hdr optimization
by Andrei Pelinescu-Onciul 02 Mar '10

02 Mar '10

Module: sip-router Branch: master Commit: e040485765e1d456c14d45de2d2c85bfd5bc5903 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e040485… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Tue Mar 2 17:41:37 2010 +0100 core: added missing parsed flags & minor get_hdr optimization - parsed flags were not set for some headers (ACCEPTCONTACT, ALLOWEVENTS, CONTENTENCODING, REFERREDBY, REJECTCONTACT, REQUESTDISPOSITION, WWW_AUTHENTICATE, PROXY_AUTHENTICATE, RETRY_AFTER). - get_hdr() now checks first if the required header type was parsed using the parsed flags. If it was not, it exists immediately (it does not try to search through all the headers anymore). --- parser/msg_parser.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/parser/msg_parser.c b/parser/msg_parser.c index 97378c7..a2a834e 100644 --- a/parser/msg_parser.c +++ b/parser/msg_parser.c @@ -364,7 +364,8 @@ int parse_headers(struct sip_msg* msg, hdr_flags_t flags, int next) case HDR_WWW_AUTHENTICATE_T: case HDR_PROXY_AUTHENTICATE_T: case HDR_RETRY_AFTER_T: - case HDR_OTHER_T: /*do nothing*/ + case HDR_OTHER_T: /* mark the type as found/parsed*/ + msg->parsed_flag|=HDR_T2F(hf->type); break; case HDR_CALLID_T: if (msg->callid==0) msg->callid=hf; @@ -830,9 +831,10 @@ struct hdr_field* get_hdr(struct sip_msg *msg, enum _hdr_types_t ht) { struct hdr_field *hdr; - for(hdr = msg->headers; hdr; hdr = hdr->next) { - if(hdr->type == ht) return hdr; - } + if (msg->parsed_flag & HDR_T2F(ht)) + for(hdr = msg->headers; hdr; hdr = hdr->next) { + if(hdr->type == ht) return hdr; + } return NULL; }

1 0

git:andrei/cancel_reason: tm: Reason header generation for local CANCELs
by Andrei Pelinescu-Onciul 02 Mar '10

02 Mar '10

Module: sip-router Branch: andrei/cancel_reason Commit: 70d5b1b4c1bf4deb1dfed13679e9a76f15e9b923 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=70d5b1b… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Mon Mar 1 18:40:19 2010 +0100 tm: Reason header generation for local CANCELs When cancel-ing branches due to final reply, 2xx or 6xx, add a Reason header (according to RFC3326). E.g.: Reason: SIP;cause=200 Internal implementation notes: the branch_bm_t/cancel_bitmap parameter of many of the reply and cancel functions was replaced with a bigger structure that contains all the information associated with the cancel: the cancel branch bitmap, the reason and reason text (optional) or the received cancel message (if any). Note that the current commit does not implement copying Reason headers from a received CANCEL, it deals only with CANCEL generated locally because of a final reply, 2xx or 6xx. --- modules/tm/t_cancel.c | 47 +++++++++++-------- modules/tm/t_cancel.h | 7 ++- modules/tm/t_fwd.c | 3 +- modules/tm/t_msgbuilder.c | 113 ++++++++++++++++++++++++++++++++++++++++---- modules/tm/t_msgbuilder.h | 6 ++- modules/tm/t_reply.c | 78 +++++++++++++++++-------------- modules/tm/t_reply.h | 37 ++++++++++++++- modules/tm/timer.c | 8 ++-- 8 files changed, 221 insertions(+), 78 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=70d…

2 1

[ openser-Patches-2826542 ] Add id parameter to pua_mi's send_publish
by SourceForge.net 02 Mar '10

02 Mar '10

Patches item #2826542, was opened at 2009-07-24 14:27 Message generated for change (Comment added) made by axlh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743022&aid=2826542&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver 1.5.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Hermann (axlh) Assigned to: Nobody/Anonymous (nobody) Summary: Add id parameter to pua_mi's send_publish Initial Comment: When using presence with dialog-info, one needs to be able to specify an id, otherwise presentity from different calls for the same presentity-uri will overwrite each other. This patch makes it possible to specify an 'id' in the MI interface for send_publish. Unfortunately it breaks backward compatibility but it's the only way to use dialog-info with MI without having to manually store a the state of the ETag in the proxy. ---------------------------------------------------------------------- >Comment By: Alex Hermann (axlh) Date: 2010-03-02 11:05 Message: I don't think changing the API in a stable release is appropriate. So, no, I didn't commit it to 1.5. It might apply to git master too, but I haven't had time to use/evaluate SR yet and I don't feel comfortable with committing without testing. ---------------------------------------------------------------------- Comment By: Daniel-Constantin Mierla (miconda) Date: 2010-03-01 20:02 Message: Just saw this one again. Alex, did you commit it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743022&aid=2826542&group_…

1 0

[ openser-Patches-2961414 ] fix for crash when Content-length too big - ID: 281827
by SourceForge.net 02 Mar '10

02 Mar '10

Patches item #2961414, was opened at 2010-03-01 19:20 Message generated for change (Comment added) made by marcushunger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743022&aid=2961414&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver 1.5.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: fix for crash when Content-length too big - ID: 281827 Initial Comment: are there any valid use cases for a content-length being bigger than the rest of of the packet? i have not tested the issue with kamailio 3.0. ---------------------------------------------------------------------- Comment By: Marcus Hunger (marcushunger) Date: 2010-03-02 10:51 Message: i retried this with vanilla-kamailio 1.5.4 downloaded from kamailio.org and it crashs. ---------------------------------------------------------------------- Comment By: Marcus Hunger (marcushunger) Date: 2010-03-01 20:11 Message: so there's already a fix? i tried this on 1.5.4, and it crashed. maybe i made a mistake merging it to my branch. i am going to check this tomorrow. ---------------------------------------------------------------------- Comment By: Daniel-Constantin Mierla (miconda) Date: 2010-03-01 19:51 Message: This should not happen, as both pairs (msg_buf,msg_len) and (body,body_len) are set internally. The issue with the nathelper was because the len was taken from content-lenght header, which can be wrong. The discussion ended in whether to auto-correct the content-lenght value or return 400 bad message. In 1.5 the fix to avoid crash was to return error to script, 400 can be sent by using sanity module. ---------------------------------------------------------------------- Comment By: Marcus Hunger (marcushunger) Date: 2010-03-01 19:22 Message: sorry, i was not logged in while posting. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743022&aid=2961414&group_…

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2010