sr-users August 2011

sr-users@lists.kamailio.org

70 participants
107 discussions

max branches
by Jon Bonilla 23 Aug '11

23 Aug '11

Hi all Is there any configuration option in kamailio 3.1 to set the max number of branches? I have a system that needs to run over 30 times to failure_route and call append_brach() from there. At 11-12 iteractions I get the following errors: ERROR: tm [t_fwd.c:651]: ERROR: add_uac: maximum number of branches exceeded ERROR: tm [t_fwd.c:1528]: ERROR: t_forward_nonack: failure to add branches ERROR: tm [tm.c:1368]: ERROR: w_t_relay_to: t_relay_to failed ERROR: tm [t_reply.c:965]: ERROR: run_failure_handlers: Error in run_top_route cheers, Jon

4 4

Testing upcoming version 3.2.0
by Daniel-Constantin Mierla 23 Aug '11

23 Aug '11

Hello, for those looking to test v3.2.0 and need some instructions, for Kamailio flavour is a wiki page showing step-by-step installation: * http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-devel-from-git Practically 3.2.0 is the current devel branch. Testing SER flavour the difference is just using FLAVOUR=ser when compiling the application. Developers as well as users are encouraged to add details about the new additions in v3.2.0 to wiki page: * http://sip-router.org/wiki/features/new-in-devel Also, please add instructions for migrating from 3.1.x to 3.2.0 to the wiki page: * http://sip-router.org/wiki/install/3.1.x-to-3.2.x Thanks, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda

1 0

Development branch frozen for v3.2.0
by Daniel-Constantin Mierla 23 Aug '11

23 Aug '11

Hello, since several hours ago, the development of new features in master branch has been frozen, to allow proper testing for release of version 3.2.0. That means no new features should be committed to GIT master branch. Just before the release (expected in 1.5months) we will create a dedicate branch for 3.2.x series and master branch will be again open for new stuff. Meanwhile, developers can use personal branches to push code in the public space. GIT master branch will be used in this period for: - bug fixing - hammering of the new features in 3.2.0 - documentation improvements - merging of duplicated modules There are two good news for 3.2.0: - the number of the new features is very impressive. Besides the old squad, we gained many new developers lately, coming with interesting contributions, therefore I am sure you'll have lot of fun testing them - the core components (transport layers, asynchronous processing, timers, locking & memory managers, a.s.o.) were barely touched since 3.0, so this is the 3rd release in a row using the new scalable core framework. That shows the maturity and there will be no much to focus on them If you need assistance while trying some new features, feel free to email to sr-dev mailing list. Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda

1 0

RFC-5766 / RFC-6062 compliant TURN clients?
by Rafal Boni 23 Aug '11

23 Aug '11

I know this might not be totally on-topic for the list, but I figured the list participants might have experience in this domain, so I'm lobbing it out there... I've got some situations where I'd like to connect users who are oftentimes sitting on very locked-down networks (ie, corporate networks) to some SIP-based VoIP infrastructure, but the idea of opening random UDP ports on the networks in question is a no-go. As a result, I'm experimenting with TURN over TCP or TLS as a solution to enable connectivity... however, I can't find any clients that implement the latest specs (X-Lite 4 appears to speak an older version of the TURN protocol; QJsip doesn't work for me; etc. etc.). Do folks here have any suggestions for TURN-compatible clients? I care mostly about PC for the time being (ie, just a proof of concept) but a PC/Mac/Linux solution would be great too. Thanks for any insights, --rafal

2 1

E2E ACK is not logged with siptrace modul kamailio
by MÉSZÁROS Mihály 22 Aug '11

22 Aug '11

Hi, I want to see all incoming and outgoing sip messages in sip trace table, but i am missing messages. I am using TLS so i can't see really trace the conversation only this way. I am wondering if it is know limitation, or an issue: I am experiencing that E2E ACK is not logged in siptrace table. I opened a ticket with the details: http://sip-router.org/tracker/index.php?do=details&task_id=144&project=1&pa… Many Thanks, Misi

3 11

New developer - Matthew Williams
by Daniel-Constantin Mierla 22 Aug '11

22 Aug '11

Hello, a new person has joined our development squad - Matthew Williams, currently working for Flowroute, USA. He is already a developer of SEMS (SIP Express Media Server) and he going to add shortly, just in time for 3.2, some Json related extensions, including a JSON-RPC client module. His GIT commit user id is: mgw. Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda

1 0

Re: [SR-Users] decode_mime_type error
by Jijo 22 Aug '11

22 Aug '11

Hi Marius, The existing implementation is done considering the limitation of decode_mime_type but somehow missed the change in parse_content_type_hdr. I agree with you that its better to do the change in decode_mime_type as it is common for lot of other callers.. Regarding the example you pointed, According to my understanding from the code, I believe that existing implementation for parse_accept_body shall work as the mime types are predefined. So in the example you pointed for second invocation 'some value' is not a defined mime type as it not matching with predefined types. The decode_mime_type returns end pointer and parse_accept_body shall process only with the valid mime type text/plain. another example with multiple mime types.., Accept: text/html, multipart/mixed In this case parse_accept_body returns 2 mime types as both are predefined in the list. Thanks Jijo On Thu, Aug 18, 2011 at 5:58 PM, Bucur Marius <bucur_marius_ovidiu(a)yahoo.com > wrote: > Hi Jijo, > > In my opinion, decode_mime_type is broken, and parse_accept_body does not > work as expected. > For example, this is a valid accept header: > > accept: text/plain;param=",some value". > > but the parse_accept_body will return -1 because the first return value of > decode_mime_type is ",some value\"". The second invocation will think "some > value\"" is a mime type, which obviously isn't. > > I must say I never saw such an accept header, but the standard permits it. > Indeed, a quick fix would be to ignore the return code when comma is found. > This must be done for other functions that call decode_mime_type > like has_body(mime) in textops. > > This is just my opinion, but I think this solution is a bit hackish since > the convention, the "promise" that decode_mime_type should respect is to > return a non-NULL, non-end pointer ONLY when there are more mime types in > the body. And it doesn't. > A lot of functions that call it rely on this. I think it is easier/more > elegant to fix the bug in the decode_mime_type then to change the function > convention in all callers. > Also, this might work for most callers, but parse_accept_body will still be > buggy, as I explained in the example above. > > Cheers, > Marius > > ________________________________ > From: Jijo <realjijo(a)gmail.com> > To: Bucur Marius <bucur_marius_ovidiu(a)yahoo.com> > Sent: Thursday, August 18, 2011 10:48 AM > Subject: Re: [SR-Users] decode_mime_type error > > > Hi Marius, > > Right, the same function is used for Accept and Content-Type. > > I don't think there is any change required for parsing Accept. In case of > Accept the function decode_mime_type is called in a loop until it find all > the media types. On the returning from decode_mime_type(), the main function > parse_accept_xxx() checks the pointer is 'comma' or not. if its comma, then > the function decode_mime_type called again and find the remaining media > types. So i think the existing implementation for Parsing Accept is fine. > > The only change required here is not return error for comma while parsing > the Content-Type. > > Thanks > Jijo > > > On Thu, Aug 18, 2011 at 12:32 PM, Bucur Marius < > bucur_marius_ovidiu(a)yahoo.com> wrote: > > Hello Jijo, > > > >You are right, multiple mime-types are not allowed. But it seems like > decode_mime_type had the purpose of also parsing the Accept header: > > > >Accept: text/html, image/jpeg, multipart > > > >hence the search for commas :). > >The only function that uses this feature and calls decode_mime_type in a > loop is parse_accept_body. The other functions that call decode_mime_type > just fail when returning ret != end, and since multiple mime types in > content-type are not allowed the behavior is fine. > >The bad thing is the Accept header can have mime parameters too (which can > contain comma). > > > >Accept = "Accept" HCOLON [ accept-range *(COMMA accept-range) > ] > >accept-range = media-range *(SEMI accept-param) > >media-range = ( "*/*" / ( m-type SLASH "*" ) / ( m-type SLASH > m-subtype ) ) *( SEMI m-parameter ) > > > >So I think the best thing would be to change decode_mime_type so that it > does a more thorough parsing (e.g. check for parameter) hence a parameter > value can contain commas (only if quoted). > > > > > >Cheers, > > > >Marius > >________________________________ > >From: Jijo <realjijo(a)gmail.com> > >To: Bucur Marius <bucur_marius_ovidiu(a)yahoo.com>; SIP Router - Kamailio > (OpenSER) and SIP Express Router (SER) - Users Mailing List < > sr-users(a)lists.sip-router.org> > >Sent: Thursday, August 18, 2011 8:04 AM > >Subject: Re: [SR-Users] decode_mime_type error > > > > > > > >Hi Marius, > > > >Thanks for the response.. I checked the other functions, but they don't > have the check for ret !=end, but they check the pointer and if it is comma > then loop through again until it find all the media types. > > > >As per the RFC3261 multiple media-types are not supoorted in the > Content-Type. So I'm not sure why the author used comma to determine > multiple media types . Probably just followed like Route or Record-Route > headers..?? > > > >Content-Type = ( "Content-Type" / "c" ) HCOLON media-type > >media-type = m-type SLASH m-subtype *(SEMI m-parameter) > >m-type = discrete-type / composite-type > >discrete-type = "text" / "image" / "audio" / "video" > >/ "application" / extension-token > >composite-type = "message" / "multipart" / extension-token > > > >Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route) > > > >Thanks > >Jijo > > > > > > > >On Thu, Aug 18, 2011 at 2:23 AM, Bucur Marius < > bucur_marius_ovidiu(a)yahoo.com> wrote: > > > >Hello Jijo, > >> > >>It seems like the decode_mime_type is a somehow broken. The comma is very > well allowed in boundary, as you said. The BNF specified in RFC2046 permits > it. > >>But, the decode_mime_type function ignores everything coming after comma. > More than that, it notifies the function caller that this content type has > multiple mime types. > >>I think the author of the function thought of something like: > >> > >>Content-Type: text/html, image/jpeg // very weird, though > >> > >>This is wrong, hence the comma can be in a parameter (like in your case). > >>I think the best fix, as you said is to remove that check, hence a > non-NULL return value doesn't mean anything (that the content type has > multiple mime types). > >>Another fix is to write a "good" decode_mime_type, that checks if the > comma is inside a parameter. I don't know if effort is worth it. > >> > >>One thing we need to do is to check if there are any functions in > Kamailio that call decode_mime_type and also perform this check (ret != > end). > >> > >>Cheers, > >>Marius > >> > >> > >>________________________________ > >>From: Jijo <realjijo(a)gmail.com> > >>To: sr-users(a)lists.sip-router.org; sr-dev(a)lists.sip-router.org > >>Sent: Wednesday, August 17, 2011 10:54 AM > >>Subject: [SR-Users] decode_mime_type error > >> > >> > >> > >>Hi All, > >> > >>The function parse_content_type_hdr() is failing in decode_mime_type() > when Content-Type parameter "boundary" has value comma as below. The error > message is "ERROR:parse_content_type_hdr: CONTENT_TYPE hdr contains " > >> "more then one mime type :-(! > >> > >>Content Type Header is as below, It works fine if the boundary value is > without comma. > >> > >>Content-Type: multipart/mixed;boundary=",AW" > >> > >>The parse_content_type_hdr() is failing in the following code, > >> > >> ret = decode_mime_type(msg->content_type->body.s, end , &mime); > >> if (ret==0) > >> goto error; > >> if (ret!=end) { > >> > >> LOG(L_INFO,"ERROR:parse_content_type_hdr: CONTENT_TYPE hdr > contains " > >> "more then one mime type :-(!\n"); > >> goto error ; > >> } > >> > >>I thought of fixing this issue by commenting the code for condition ret > !=end. I'm not sure why we we need that check, as mime variable has the > information to process the content. > >> > >>Please let me know if you see any impact. > >> > >>Thanks > >>Jijo > >> > >> > >> > >> > >> > >>_______________________________________________ > >>SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > >>sr-users(a)lists.sip-router.org > >>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >> > >>_______________________________________________ > >>SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > >>sr-users(a)lists.sip-router.org > >>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >> > > >

2 2

min expires question
by Fabian Borot 22 Aug '11

22 Aug '11

Hello This is how my registrar module is configured, hoping that min-expires set to 30 wont allow registration attempts more often than 30 seconds, but if I configure a UAC to register every 15 seconds I see that kamailio allows it. Shouldn't it reply with "422 Session Interval Too Small" or "423 Interval Too Brief"? # ----- registrar params ----- modparam("registrar", "default_expires", 120) modparam("registrar", "min_expires", 30) modparam("registrar", "method_filtering", 1) /* uncomment the next line to disable parallel forking via location */ # modparam("registrar", "append_branches", 0) /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10) 131.380336 192.168.1.6 -> 192.168.1.194 SIP Request: REGISTER sip:192.168.1.194 131.381174 192.168.1.194 -> 192.168.1.6 SIP Status: 200 OK (1 bindings) 144.386014 192.168.1.6 -> 192.168.1.194 SIP Request: REGISTER sip:192.168.1.194 144.387110 192.168.1.194 -> 192.168.1.6 SIP Status: 200 OK (1 bindings) 157.395358 192.168.1.6 -> 192.168.1.194 SIP Request: REGISTER sip:192.168.1.194 157.396340 192.168.1.194 -> 192.168.1.6 SIP Status: 200 OK (1 bindings) 170.404905 192.168.1.6 -> 192.168.1.194 SIP Request: REGISTER sip:192.168.1.194 170.405771 192.168.1.194 -> 192.168.1.6 SIP Status: 200 OK (1 bindings) 183.414375 192.168.1.6 -> 192.168.1.194 SIP Request: REGISTER sip:192.168.1.194 183.415217 192.168.1.194 -> 192.168.1.6 SIP Status: 200 OK (1 bindings) txs fborot

3 4

Sip Router Issues (Topoh's module)
by Richard DEMONGEOT 22 Aug '11

22 Aug '11

Dear all, I've encountered two issues with Sip Router. Build : Kamailio 3.1.4 for Squeeze (Kamailio's debian Packages). When i'm using Topoh with Call-ID encoding, instruction dlg_bye("ALL") generate me an error on logfiles : Aug 4 17:46:26 kamtest /usr/sbin/kamailio[25267]: ERROR: topoh [th_mask.c:166]: invalid input string"dd04db6ccc7074deb9f8a1160946d331@0:0:0:0:0:0:0:0" Aug 4 17:46:26 kamtest /usr/sbin/kamailio[25267]: ERROR: topoh [th_msg.c:480]: cannot decode callid Aug 4 17:46:26 kamtest /usr/sbin/kamailio[25268]: ERROR: topoh [th_mask.c:166]: invalid input string"dd04db6ccc7074deb9f8a1160946d331@0:0:0:0:0:0:0:0" Aug 4 17:46:26 kamtest /usr/sbin/kamailio[25268]: ERROR: topoh [th_msg.c:480]: cannot decode callid Only "INCOMING LEG" is ended, and "OUTGOING LEG", with call-ID encoded continue. Have you any idea about this problem? Can we use dlg_bye("ALL") with call-id encoding? Best regards,

2 5

10 Years SER Conference, Berlin - full booked
by Daniel-Constantin Mierla 22 Aug '11

22 Aug '11

Hello, the 10 years SER conference in Berlin is full booked, meaning that new registrations will be accepted only if someone that registered previously will cancel his/her participation. Since we just discovered such a situation, in the case you did register and you haven't received a confirmation email (not the one automatically generated at registration time, but a second one), please reply to me or write to registration(a)lists.sip-router.org telling the date when you did the registration and we will try to solve it. Looking forward to meeting many of you soon in Berlin! Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
11
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users August 2011