sr-dev June 2012

sr-dev@lists.kamailio.org

31 participants
250 discussions

[tracker] Comment added: Kamailio does not handle HTTP Via: headers in requests and responses

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#237 - Kamailio does not handle HTTP Via: headers in requests and responses User who did this - Daniel-Constantin Mierla (miconda) ---------- OK, so if there is no special handling required, avoiding the parsing error should be easy. Search for '\nVia:' and if found, replace it with something that won't break the buffer, like '\nXia:', before going to the parser - I think this part is all in the xhttp module. Not generating Via header has some existing mechanism, used by msg_apply_changes(), but it is for requests. Perhaps same approach can be used for replies to say the via should not be added. I guess, there has to be added a new kind of reply function to be used internally between modules, iirc, xhttp_reply() binds to sl module. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=237#comment696 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.

12 years, 6 months

[tracker] Comment added: Kamailio does not handle HTTP Via: headers in requests and responses

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#237 - Kamailio does not handle HTTP Via: headers in requests and responses User who did this - Peter Dunkley (pd) ---------- Unfortunately there is no way to enforce direct client-server communication. Some networks only allow HTTP through a network proxy and others have in-line (and unavoidable) proxies as part of their Internet routing. I don't believe Kamailio needs to do anything clever with an HTTP Via: (it is just added by gateways and proxies for their use). I think that Kamailio needs to: - not generate a parser error it receives an HTTP Via:, and - not put Via: headers into HTTP responses at all >From RFC 2616: The Via general-header field MUST be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822 [9] and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain. I'm not sure how easy this is to do (particularly the not putting Via: headers into responses part). ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=237#comment695 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.

12 years, 6 months

[tracker] Comment added: Kamailio does not handle HTTP Via: headers in requests and responses

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#237 - Kamailio does not handle HTTP Via: headers in requests and responses User who did this - Daniel-Constantin Mierla (miconda) ---------- Indeed the embedded http handling is designed for direct client-server communication. I haven't read the specs, is http via requiring special processing in terms of routing? Or is just for informational purposes? ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=237#comment694 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.

12 years, 6 months

[tracker] Comment added: Kamailio does not handle HTTP Via: headers in requests and responses

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#237 - Kamailio does not handle HTTP Via: headers in requests and responses User who did this - Peter Dunkley (pd) ---------- Correction: HTTP Via: headers are defined in RFC 2616 section 14.45 ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=237#comment693 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.

12 years, 6 months

[tracker] Task opened: Kamailio does not handle HTTP Via: headers in requests and responses

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Peter Dunkley (pd) Attached to Project - sip-router Summary - Kamailio does not handle HTTP Via: headers in requests and responses Task Type - Bug Report Category - Core Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Normal Reported Version - 3.2 Due in Version - Undecided Due Date - Undecided Details - Via: is a valid HTTP header (RFC 2616 section 14.5) in requests and responses. Unfortunately, the format of an HTTP Via: and a SIP Via: is different. This means that if you are handling HTTP (for example, for XCAP) on Kamailio and receive a valid HTTP request with a correctly formed HTTP Via: header you get a parser error and the request is not handled. Similarly, each HTTP response sent by Kamailio contains a SIP Via: header (which is not a valid HTTP Via: header) and this can cause problems with HTTP clients and proxies. This issue was observed when the XCAP client was on a network that used a Squid HTTP proxy for all HTTP traffic. The Squid proxy was inserting and processing HTTP Via: headers. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=237 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.

12 years, 6 months

git:master: ndb_redis: remove warning: implicit declaration of function redisc_free_reply

by Vicente Hernando

Module: sip-router Branch: master Commit: 1835cd92f2475ce12a79d972ca6548fbbb857ce4 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=1835cd9… Author: Vicente Hernando <vhernando(a)systemonenoc.com> Committer: Vicente Hernando <vhernando(a)systemonenoc.com> Date: Tue Jun 19 13:31:42 2012 -0400 ndb_redis: remove warning: implicit declaration of function redisc_free_reply --- modules/ndb_redis/redis_client.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/modules/ndb_redis/redis_client.h b/modules/ndb_redis/redis_client.h index 7128923..f4d29f4 100644 --- a/modules/ndb_redis/redis_client.h +++ b/modules/ndb_redis/redis_client.h @@ -60,4 +60,5 @@ typedef struct redisc_pv { } redisc_pv_t; redisc_reply_t *redisc_get_reply(str *name); +int redisc_free_reply(str *name); #endif

12 years, 6 months

t_suspend() in TMCB_ON_FAILURE?

by Martin Hoffmann

Hi guys, since tm is a bit, er, complex and breakage is not immediately obvious, I'd rather ask: Is it safe to call t_suspend() from the TMCB_ON_FAILURE callback? The idea is to always delay the transaction until there either is a 200 OK or it times out. In other words, does this work: static void failure_handler(struct cell *t, int type, struct tmcb_params *params) { if (params->repl != FAKED_REPLY) { tmb.t_suspend(params->req, &t->tindex, &t->tlabel); } } If it doesn't work, any better idea? Regards, Martin

12 years, 6 months

git:master: core: typedefed avp search state structure

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: b5af0f6622d592f52f53b8c8572fcfe73fab867f URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=b5af0f6… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Tue Jun 19 15:05:33 2012 +0200 core: typedefed avp search state structure --- usr_avp.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/usr_avp.h b/usr_avp.h index b40ccdb..3204ff1 100644 --- a/usr_avp.h +++ b/usr_avp.h @@ -115,13 +115,13 @@ typedef struct avp_ident { /* * AVP search state */ -struct search_state { +typedef struct search_state { avp_flags_t flags; /* Type of search and additional flags */ avp_id_t id; avp_name_t name; avp_t* avp; /* Current AVP */ // regex_t* search_re; /* Compiled regular expression */ -}; +} avp_search_state_t; /* avp aliases structs*/ typedef struct avp_spec {

12 years, 6 months

git:master: pv: new variable $cnt(...) to count the number of other array variables

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: 06982365e6d361d8fb78e1ece579eb1de87db643 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0698236… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Tue Jun 19 15:06:03 2012 +0200 pv: new variable $cnt(...) to count the number of other array variables - for now it supports counting AVPS - $cnt($avp(x) - returns the number of how many AVPs with name x exist - future plans - count headers with same name, xavps ... --- modules_k/pv/pv.c | 3 ++ modules_k/pv/pv_core.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++ modules_k/pv/pv_core.h | 6 ++++ 3 files changed, 69 insertions(+), 0 deletions(-) diff --git a/modules_k/pv/pv.c b/modules_k/pv/pv.c index 93955a1..6b7dccb 100644 --- a/modules_k/pv/pv.c +++ b/modules_k/pv/pv.c @@ -132,6 +132,9 @@ static pv_export_t mod_pvs[] = { {{"cl", (sizeof("cl")-1)}, /* */ PVT_OTHER, pv_get_content_length, 0, 0, 0, 0, 0}, + {{"cnt", sizeof("cnt")-1}, + PVT_OTHER, pv_get_cnt, 0, + pv_parse_cnt_name, 0, 0, 0 }, {{"cs", (sizeof("cs")-1)}, /* */ PVT_OTHER, pv_get_cseq, 0, 0, 0, 0, 0}, diff --git a/modules_k/pv/pv_core.c b/modules_k/pv/pv_core.c index 370ec1a..2a27490 100644 --- a/modules_k/pv/pv_core.c +++ b/modules_k/pv/pv_core.c @@ -1587,6 +1587,34 @@ int pv_get_server_id(struct sip_msg *msg, pv_param_t *param, return pv_get_sintval(msg, param, res, server_id); } +int pv_get_cnt(struct sip_msg *msg, pv_param_t *param, + pv_value_t *res) +{ + int_str avp_name; + unsigned short avp_type = 0; + avp_search_state_t state; + pv_spec_t *pv=NULL; + unsigned int n = 0; + avp_t *avp; + + pv = (pv_spec_t*)param->pvn.u.dname; + if(pv==NULL) + return pv_get_null(msg, param, res); + + if(pv_get_avp_name(0, &pv->pvp, &avp_name, &avp_type)!=0) + { + LM_ERR("invalid AVP definition\n"); + return pv_get_null(msg, param, res); + } + avp=search_first_avp(avp_type, avp_name, NULL, &state); + while(avp) { + n++; + avp=search_next_avp(&state, NULL); + } + + return pv_get_uintval(msg, param, res, n); +} + /********* end PV get functions *********/ @@ -2398,3 +2426,35 @@ error: return -1; } +int pv_parse_cnt_name(pv_spec_p sp, str *in) +{ + pv_spec_t *pv=NULL; + + if(in->s==NULL || in->len<=0) + return -1; + + pv = (pv_spec_t*)pkg_malloc(sizeof(pv_spec_t)); + if(pv==NULL) + return -1; + + memset(pv, 0, sizeof(pv_spec_t)); + + if(pv_parse_spec(in, pv)==NULL) + goto error; + + if(pv->type!=PVT_AVP) + { + LM_ERR("expected avp name instead of [%.*s]\n", in->len, in->s); + goto error; + } + + sp->pvp.pvn.u.dname = (void*)pv; + sp->pvp.pvn.type = PV_NAME_PVAR; + return 0; + +error: + LM_ERR("invalid pv name [%.*s]\n", in->len, in->s); + if(pv!=NULL) + pkg_free(pv); + return -1; +} diff --git a/modules_k/pv/pv_core.h b/modules_k/pv/pv_core.h index 4fb83d5..0149d24 100644 --- a/modules_k/pv/pv_core.h +++ b/modules_k/pv/pv_core.h @@ -201,6 +201,10 @@ int pv_get_version(struct sip_msg *msg, pv_param_t *param, int pv_get_server_id(struct sip_msg *msg, pv_param_t *param, pv_value_t *res); + +int pv_get_cnt(struct sip_msg *msg, pv_param_t *param, + pv_value_t *res); + /********* end PV get functions *********/ /********* start PV set functions *********/ @@ -270,5 +274,7 @@ int pv_parse_scriptvar_name(pv_spec_p sp, str *in); int pv_parse_hdr_name(pv_spec_p sp, str *in); +int pv_parse_cnt_name(pv_spec_p sp, str *in); + #endif

12 years, 6 months

dialplan and empty repl_exp

by Andreas Granig

Hi all, We ran into an issue with dialplan in regex mode when we leave the repl_exp empty. Consider this scenario: if(dp_translate("1", "$rU/$var(out)") { # translation successful $rU = $var(out); } If the dialplan entry has match_exp="^999" and subst_exp="^999" and repl_exp="" and my $rU is "999123", I'd expect $var(out) to be "123", because an empty replacement part is perfectly valid for a regex. The result however is that $var(out) is untouched, so whatever $var(out) was before the function call, will end up in $rU in this case. That's not what I'd expect if dp_translate returns success. It should be fairly easy to fix and we can provide a patch for that, I'd just want to get some feedback if you agree on changing dp_translate behavior in such a case, as it might break existing scripts if you rely on the current way of working. Comments? Andreas

12 years, 6 months

← Newer
1
...
5
6
7
8
9
10
11
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2012