sr-dev June 2012

sr-dev@lists.kamailio.org

31 participants
251 discussions

[tracker] Comment added: Kamailio does not handle HTTP Via: headers in requests and responses
by sip-router 20 Jun '12

20 Jun '12

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) ---------- Btw, the sip via was ignored so far by the http clients, not sure what happens in the http proxies ... Not getting the parsing error is probably higher priority, fortunately looks easy enough. And it just came in my mind, we can hook up in the core for sent replies and replace '\nVia:' with other same-size-and-format token if it is HTTP. Something similar does topoh to hide the SIP sensitive headers. But it is not really that clean, the hook callback impacting all replies, including SIP (even if not replaced, it will be some extra check to detect is sip vs http). ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=237#comment697 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] Comment added: Kamailio does not handle HTTP Via: headers in requests and responses
by sip-router 20 Jun '12

20 Jun '12

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.

1 0

[tracker] Comment added: Kamailio does not handle HTTP Via: headers in requests and responses
by sip-router 20 Jun '12

20 Jun '12

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.

1 0

[tracker] Comment added: Kamailio does not handle HTTP Via: headers in requests and responses
by sip-router 20 Jun '12

20 Jun '12

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.

1 0

[tracker] Comment added: Kamailio does not handle HTTP Via: headers in requests and responses
by sip-router 20 Jun '12

20 Jun '12

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.

1 0

[tracker] Task opened: Kamailio does not handle HTTP Via: headers in requests and responses
by sip-router 20 Jun '12

20 Jun '12

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.

1 0

git:master: ndb_redis: remove warning: implicit declaration of function redisc_free_reply
by Vicente Hernando 19 Jun '12

19 Jun '12

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

1 0

t_suspend() in TMCB_ON_FAILURE?
by Martin Hoffmann 19 Jun '12

19 Jun '12

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

1 0

git:master: core: typedefed avp search state structure
by Daniel-Constantin Mierla 19 Jun '12

19 Jun '12

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 {

1 0

git:master: pv: new variable $cnt(...) to count the number of other array variables
by Daniel-Constantin Mierla 19 Jun '12

19 Jun '12

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

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2012