sr-dev February 2014

sr-dev@lists.kamailio.org

38 participants
235 discussions

[tracker] Task closed: call_control: Passthrough sip_application

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#395 - call_control: Passthrough sip_application User who did this - Daniel-Constantin Mierla (miconda) Reason for closing: Implemented Additional comments about closing: Thanks for the patch, it was merged to master branch. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=395 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.

10 years, 9 months

git:master: call_control: Passthrough sip_application

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: 0a4519af5c1ea3f61362fba7451eb4acc479d488 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0a4519a… Author: David M. Lee <dlee(a)digium.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Mon Feb 10 15:22:11 2014 -0600 call_control: Passthrough sip_application Current patches being submitted to CDRTool and the call_control daemon allow for SIP application type to be specified. This allows audio or video services to be rated differently, or even different ratings for application subtypes (audio.inbound vs. audio.outbound). This patch allows the sip_application value to be passed through to the call_control daemon. --- modules/call_control/call_control.c | 42 ++++++++++++++++++++++++++++++++++- 1 files changed, 41 insertions(+), 1 deletions(-) diff --git a/modules/call_control/call_control.c b/modules/call_control/call_control.c index 2ba7a50..725d638 100644 --- a/modules/call_control/call_control.c +++ b/modules/call_control/call_control.c @@ -59,6 +59,7 @@ MODULE_VERSION #define CANONICAL_URI_AVP_SPEC "$avp(s:can_uri)" #define SIGNALING_IP_AVP_SPEC "$avp(s:signaling_ip)" +#define SIP_APPLICATION_AVP_SPEC "$avp(s:sip_application)" // Although `AF_LOCAL' is mandated by POSIX.1g, `AF_UNIX' is portable to // more systems. `AF_UNIX' was the traditional name stemming from BSD, so @@ -134,6 +135,9 @@ static AVP_Param canonical_uri_avp = {str_init(CANONICAL_URI_AVP_SPEC), {0}, 0}; /* The AVP where the caller signaling IP is stored (if defined) */ static AVP_Param signaling_ip_avp = {str_init(SIGNALING_IP_AVP_SPEC), {0}, 0}; +/* The AVP where the SIP application type is stored (if defined) */ +static AVP_Param sip_application_avp = {str_init(SIP_APPLICATION_AVP_SPEC), {0}, 0}; + struct dlg_binds dlg_api; static int dialog_flag = -1; @@ -157,6 +161,7 @@ static param_export_t parameters[] = { {"diverter_avp_id", INT_PARAM, &diverter_avp_id}, {"canonical_uri_avp", STR_PARAM, &(canonical_uri_avp.spec.s)}, {"signaling_ip_avp", STR_PARAM, &(signaling_ip_avp.spec.s)}, + {"sip_application_avp", STR_PARAM, &(sip_application_avp.spec.s)}, {0, 0, 0} }; @@ -204,6 +209,7 @@ typedef struct CallInfo { str callid; str from; str from_tag; + str sip_application; } CallInfo; @@ -416,6 +422,22 @@ get_signaling_ip(struct sip_msg* msg) return value.s; } +// Get SIP application type +static str +get_sip_application(struct sip_msg* msg) +{ + int_str value; + + if (!search_first_avp(sip_application_avp.type | AVP_VAL_STR, + sip_application_avp.name, &value, NULL) || + !value.s.s || value.s.len==0) { + + value.s.s = "audio"; + value.s.len = strlen(value.s.s); + } + + return value.s; +} static str get_diverter(struct sip_msg *msg) @@ -534,6 +556,7 @@ get_call_info(struct sip_msg *msg, CallControlAction action) call_info.ruri = get_canonical_request_uri(msg); call_info.diverter = get_diverter(msg); call_info.source_ip = get_signaling_ip(msg); + call_info.sip_application = get_sip_application(msg); } call_info.action = action; @@ -604,13 +627,15 @@ make_default_request(CallInfo *call) "callid: %.*s\r\n" "from: %.*s\r\n" "fromtag: %.*s\r\n" + "sip_application: %.*s\r\n" "\r\n", call->ruri.len, call->ruri.s, call->diverter.len, call->diverter.s, call->source_ip.len, call->source_ip.s, call->callid.len, call->callid.s, call->from.len, call->from.s, - call->from_tag.len, call->from_tag.s); + call->from_tag.len, call->from_tag.s, + call->sip_application.len, call->sip_application.s); if (len >= sizeof(request)) { LOG(L_ERR, "callcontrol request is longer than %ld bytes\n", (unsigned long)sizeof(request)); @@ -1073,6 +1098,21 @@ mod_init(void) return -1; } + // initialize the sip_application_avp structure + if (sip_application_avp.spec.s==NULL || *(sip_application_avp.spec.s)==0) { + LOG(L_ERR, "missing/empty sip_application_avp parameter. using default.\n"); + sip_application_avp.spec.s = SIP_APPLICATION_AVP_SPEC; + } + sip_application_avp.spec.len = strlen(sip_application_avp.spec.s); + if (pv_parse_spec(&(sip_application_avp.spec), &avp_spec)==0 || avp_spec.type!=PVT_AVP) { + LOG(L_CRIT, "invalid AVP specification for sip_application_avp: `%s'\n", sip_application_avp.spec.s); + return -1; + } + if (pv_get_avp_name(0, &(avp_spec.pvp), &(sip_application_avp.name), &(sip_application_avp.type))!=0) { + LOG(L_CRIT, "invalid AVP specification for sip_application_avp: `%s'\n", sip_application_avp.spec.s); + return -1; + } + // bind to the dialog API if (load_dlg_api(&dlg_api)!=0) { LOG(L_CRIT, "cannot load the dialog module API\n");

10 years, 9 months

[tracker] Comment added: Invalide tel INVITE crashes 4.0.3

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#348 - Invalide tel INVITE crashes 4.0.3 User who did this - Daniel-Constantin Mierla (miconda) ---------- Is this still an issue? When I tried it worked and then no follow up... ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=348#comment1306 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.

10 years, 9 months

[tracker] Comment added: Bug in tm with topoh modules - segfault on callid comparison.

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#390 - Bug in tm with topoh modules - segfault on callid comparison. User who did this - Daniel-Constantin Mierla (miconda) ---------- Added checks to topoh to handle local generated requests and their responses without trying to hide/unhide headers -- there is nothing to protect in such case. Can you test with next patches? http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=41f12e0… http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=376d8b3… If all ok, I will backport. ---------- More information can be found at the following URL: https://sip-router.org/tracker/index.php?do=details&task_id=390#comment1305 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.

10 years, 9 months

git:master: topoh: let replies for CANCEL requests be handled

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: 376d8b3972d96b70d1e12cc57104475b2ee7ade8 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=376d8b3… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Feb 21 18:26:34 2014 +0100 topoh: let replies for CANCEL requests be handled - CANCEL is hop by hop, but can have the call-id hidden when sending out --- modules/topoh/topoh_mod.c | 11 +++-------- 1 files changed, 3 insertions(+), 8 deletions(-) diff --git a/modules/topoh/topoh_mod.c b/modules/topoh/topoh_mod.c index 698f853..b533945 100644 --- a/modules/topoh/topoh_mod.c +++ b/modules/topoh/topoh_mod.c @@ -318,8 +318,9 @@ int th_msg_received(void *data) if(msg.via2==0) { /* one Via in received reply -- it is for local generated request - * - nothing to unhide */ - goto done; + * - nothing to unhide unless is CANCEL/ACK */ + if((get_cseq(&msg)->method_id)&(METHOD_CANCEL)) + goto done; } th_unmask_via(&msg, &th_cookie_value); @@ -385,12 +386,6 @@ int th_msg_sent(void *data) th_del_cookie(&msg); if(msg.first_line.type==SIP_REQUEST) { - if(msg.via2==0) - { - /* one Via in request sent out -- it is local generated - * - nothing to hide */ - goto done; - } direction = (th_cookie_value.s[0]=='u')?1:0; /* upstream/downstram */ dialog = (get_to(&msg)->tag_value.len>0)?1:0; local = (th_cookie_value.s[0]!='d'&&th_cookie_value.s[0]!='u')?1:0;

10 years, 9 months

git:master: topoh: don't encode/decode content for local generated messages

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: 41f12e01b20a6b32d26297fbdf6ce17d40823ef2 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=41f12e0… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Feb 21 17:58:19 2014 +0100 topoh: don't encode/decode content for local generated messages - requests generated by kamailio don't have headers that should be hidden - replies to them don't have anything hidden - update as part of report from FS#390 --- modules/topoh/topoh_mod.c | 20 ++++++++++++++++++++ 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/modules/topoh/topoh_mod.c b/modules/topoh/topoh_mod.c index 28a53bb..698f853 100644 --- a/modules/topoh/topoh_mod.c +++ b/modules/topoh/topoh_mod.c @@ -222,6 +222,13 @@ int th_prepare_msg(sip_msg_t *msg) return 2; } + /* force 2nd via parsing here - it helps checking it later */ + if (parse_headers(msg, HDR_VIA2_F, 0)==-1 + || (msg->via2==0) || (msg->via2->error!=PARSE_OK)) + { + LM_DBG("no second via in this message \n"); + } + if(parse_from_header(msg)<0) { LM_ERR("cannot parse FROM header\n"); @@ -308,6 +315,13 @@ int th_msg_received(void *data) } } else { /* reply */ + if(msg.via2==0) + { + /* one Via in received reply -- it is for local generated request + * - nothing to unhide */ + goto done; + } + th_unmask_via(&msg, &th_cookie_value); th_flip_record_route(&msg, 0); if(th_cookie_value.s[0]=='u') @@ -371,6 +385,12 @@ int th_msg_sent(void *data) th_del_cookie(&msg); if(msg.first_line.type==SIP_REQUEST) { + if(msg.via2==0) + { + /* one Via in request sent out -- it is local generated + * - nothing to hide */ + goto done; + } direction = (th_cookie_value.s[0]=='u')?1:0; /* upstream/downstram */ dialog = (get_to(&msg)->tag_value.len>0)?1:0; local = (th_cookie_value.s[0]!='d'&&th_cookie_value.s[0]!='u')?1:0;

10 years, 9 months

Build B2BUA using Kamailio

by Saurabh Sinha

Hi All, I am planning to use Kamailio, to build a B2BUA with the following functionalities: - Topology Hiding (SIP: To, From, Call-ID, P-Asserted-ID) - Topology Hiding (SDP: Changing SDP info - and act as an RTP Proxy) - Perform - NAPTR ENUM Query - To Release call (If Max Duration Reached) - Generate CDRs. [Note: This is somewhat like a light SBC service] Now, my question is how to develop this service over Kamailio. Does Kamailio provide any Development APIs, which this B2BUA can use? OR I need to enhance or built new Kamailio modules? >From the initial understanding, I got to know, Kamailio maintains SIP Transactions, and NOT the SIP Dialog, and basically I need to build this. It will be great if someone can give me any leads on this front. Thanks, SS ________________________________ The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, please immediately alert the sender by reply e-mail and then delete this message. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. R Systems has taken every reasonable precaution to minimize the risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment.

10 years, 9 months

[tracker] Comment added: Crash in kamailio core - timeout on forked destinations

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#384 - Crash in kamailio core - timeout on forked destinations User who did this - Daniel-Constantin Mierla (miconda) ---------- Was there any resolution to this? I see the message from Carsten mentioning a take over. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=384#comment1304 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.

10 years, 9 months

[tracker] Comment added: Kamailio doesn't to handle any SIP message at all after several dialogs... (CPU high usage)

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#397 - Kamailio doesn't to handle any SIP message at all after several dialogs... (CPU high usage) User who did this - Daniel-Constantin Mierla (miconda) ---------- Btw, if you want to crash it, kill with signal 6 (abort). But getting backtrace by attaching with gdb to the process by pid is better to be sure the corefiles don't overwrite. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=397#comment1303 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.

10 years, 9 months

[tracker] Comment added: fixes for memory leak in TLS module

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#380 - fixes for memory leak in TLS module User who did this - Daniel-Constantin Mierla (miconda) ---------- The patch was backported to 4.1 a while ago. For 4.0 it gives conflicts, so has to be manually crafted. It would be good if you can send the patch for atomic_t. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=380#comment1302 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.

10 years, 9 months

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev February 2014