sr-users-requ...@lists.sip-router.org wrote:
>Send sr-users mailing list submissions to > sr-users@lists.sip-router.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >or, via email, send a message with subject or body 'help' to > sr-users-requ...@lists.sip-router.org > >You can reach the person managing the list at > sr-users-ow...@lists.sip-router.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of sr-users digest..." > > >Today's Topics: > > 1. Aliases Using the Default Script; (David J.) > 2. Re: Green VoIP - energy efficiency and performances of v3.0 > (Jan Janak) > 3. Kamailio v3.1.4 Released (Daniel-Constantin Mierla) > 4. Re: ser_ctl / serweb (caio) > 5. Re: [OT] IETF SIMPLE WG will destroy MSRP with the new > draft-ietf-simple-msrp-sessmatch-11 (I?aki Baz Castillo) > 6. Re: [OT] IETF SIMPLE WG will destroy MSRP with the new > draft-ietf-simple-msrp-sessmatch-11 (Daniel-Constantin Mierla) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 26 May 2011 14:27:55 -0400 >From: "David J." <da...@styleflare.com> >Subject: [SR-Users] Aliases Using the Default Script; >To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List" <sr-users@lists.sip-router.org> >Message-ID: <4dde9bab.4060...@styleflare.com> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >I am using the kamailio default script on 3.1.3. > >I was wondering what happens when I added an Alias in dbaliases? > >For example if I add 18005551...@mydomain.com alias to 1...@mydomain.com > >when an invite comes in; it works perfect I got a 200 back. (1001 Device >rings.) > >If I add another alias to a remote server; ie. > >18005551...@mydomain.com alias to 1800555...@someotherdomain.com > >I get a 404 back. > >I wonder what happens internally? > >What should I modify to enable this case; > >Thanks. > > > >------------------------------ > >Message: 2 >Date: Thu, 26 May 2011 20:49:39 +0200 >From: Jan Janak <j...@ryngle.com> >Subject: Re: [SR-Users] Green VoIP - energy efficiency and > performances of v3.0 >To: mico...@gmail.com >Cc: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\) > - Users Mailing List" <sr-users@lists.sip-router.org>, sr-dev > <sr-...@lists.sip-router.org> >Message-ID: <banlktikub_iwbdeuqk977-ecmmho4de...@mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >No, I turned it off. > >-Jan > >On Thu, May 26, 2011 at 11:50, Daniel-Constantin Mierla ><mico...@gmail.com> wrote: >> Hello, >> >> out of curiosity, since you used the sources from GIT - was memory debugging >> on? It is usually enabled in master branch and that could have some impact >> in memory usage and performances... >> >> Thanks, >> Daniel >> >> On 5/25/11 3:00 PM, Jan Janak wrote: >>> >>> On Wed, May 25, 2011 at 06:54, Jeremya<jer...@electrosilk.net> ?wrote: >>>> >>>> These figures pale into insignificance compared to the power required >>>> for standard SIP devices - typically 5-8 watts per device multiplied by >>>> the number of devices. >>>> >>>> When you factor in Gigabit Ethernet the power ups significantly. >>>> >>>> Optimisation at the server level is not significant on any scale. >>>> Optimisation on communications power: i.e. end-devices, DSL& ?switches >>>> is where the power savings are important. >>> >>> Sure, the total power consumption of the whole system is dominated by >>> the power consumption of end-point devices, there's no doubt about >>> that and the paper says that. >>> >>> Nevertheless, as an ITSP you are typically paying for the energy >>> consumed by your servers and in that case knowing what you can expect >>> and how many servers you need is useful. Modern data-center servers >>> have significant base-line power consumption and a portion of that >>> needs to be attributed to the SIP service running on those servers. >>> >>> -Jan >>> >>>> Daniel-Constantin Mierla wrote: >>>>> >>>>> Hello, >>>>> >>>>> Jan Janak conducted a very interesting research project regarding >>>>> energy efficiency of VoIP systems during 2010, a collaboration between >>>>> iptel.org and Columbia University. >>>>> >>>>> The team used the source code from sip-router.org GIT repository from >>>>> January 2010, which corresponds to Kamailio (former OpenSER) and SER >>>>> v3.0. The latest stable series v3.1 shares the same internal >>>>> architecture with v3.0. >>>>> >>>>> As part of the research work, Jan could also gather some figures about >>>>> capacity and performances of v3.0 with a quite complex configuration >>>>> file: etc/sip-router-oob.cfg (involving authentication and NAT >>>>> traversal as well). >>>>> >>>>> You can read the paper about energy efficiency at: >>>>> >>>>> - Green VoIP Article: http://asipto.com/u/2j >>>>> >>>>> The draft notes about capacity and performances of v3.0 are available >>>>> at: >>>>> >>>>> - Performances and Capacity for v3.0 Wiki page: http://asipto.com/u/2k >>>>> >>>>> Some interesting results: >>>>> >>>>> - one instance of SIP server with 500 000 online users (mixed users ? >>>>> behind and not NAT routers) ? consumed energy 210W >>>>> - one instance of SIP server with 1 000 000 online users (no NAT >>>>> involved) ? consumed energy 190W >>>>> - on a 32-bit machine with 4GB of memory and with 2.5GB reserved for >>>>> SIP server, the server could support 43 000 simultaneous TLS >>>>> connections ? consumed energy 203W >>>>> - one SIP server instance with 80 000 permanent TCP connections, the >>>>> SIP server could still handle at least 1000 requests per second and a >>>>> connection arrival rate of 1000 new connections per second, done for >>>>> 20 000 new connections. CPU load generated by the SIP server was from >>>>> 6% to 8%. >>>>> >>>>> I added a new section to the draft notes to list the enhancements done >>>>> for the latest stable release (v3.1.x) that contribute to performance >>>>> improvements, like asynchronous TLS, fine tuning of memory for TLS >>>>> connections and raw UDP sockets. >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>> >>>> _______________________________________________ >>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>>> sr-users@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@lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> -- >> Daniel-Constantin Mierla >> http://www.asipto.com >> >> > > > >------------------------------ > >Message: 3 >Date: Thu, 26 May 2011 21:00:42 +0200 >From: Daniel-Constantin Mierla <mico...@gmail.com> >Subject: [SR-Users] Kamailio v3.1.4 Released >To: kamailio <sr-users@lists.sip-router.org>, sr-dev > <sr-...@lists.sip-router.org>, busin...@lists.kamailio.org >Message-ID: <4ddea35a.7070...@gmail.com> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Hello, > >Kamailio SIP Server v3.1.4 stable release is out. > >This is a maintenance release of latest stable branch, 3.1, that >includes fixes since release of v3.1.3. There is no change to database >schema or configuration language structure. Deployments running previous >v3.1.x versions are strongly recommended to be upgraded to v3.1.4. > >For more details about version 3.1.4, visit: > >http://www.kamailio.org/w/2011/05/kamailio-v3-1-4-released/ > >Cheers, >Daniel > >-- >Daniel-Constantin Mierla -- http://www.asipto.com >http://linkedin.com/in/miconda -- http://twitter.com/miconda > > > > >------------------------------ > >Message: 4 >Date: Thu, 26 May 2011 17:59:42 -0300 >From: caio <elc...@gmail.com> >Subject: Re: [SR-Users] ser_ctl / serweb >To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List" <sr-users@lists.sip-router.org> >Message-ID: <BANLkTik+dnTp-egK2xy1ua=tpnccadu...@mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >Hello, > >Anyone know if ser_ctl (python utility) will be merged into master? Or is >going to be deprecated? >If it still alive, are there any examples/docs of the usage for DB users >provisoining? >kamctl and kamdbctl are recomended for its substitution? > >Which utility will be official for sip-router? >Sorry if it already were discussed, but I didn't find comments about it >since 2010. > >Thank you >Claudio > >On Tue, May 24, 2011 at 11:14 AM, Claudio Furrer <elc...@gmail.com> wrote: > >> Hi all, >> >> Just want to ask if ser_ctl application will be merged into sr3.1 or future >> releases. >> By the moment I've found it here [1], [2] or [3]. >> >> Is it full compatible with sip-router v3.x? >> >> I know kamctl and kamdbctl would be suggested but these are for kamailio >> flavour. I don't find too much work based on SER flavour regarding to >> database/users administration and web provisioning. >> BTW, siremis only works with kamailio db structures, but for sip-router v3 >> ser-flavoured only found serweb 2.x here [4] and [5] which I don't know if >> is >> it working well with the current new releases of the project. >> >> I would appreciate if someone can advice me if kamailio is the way to go, >> because have find that sip-router or ser flavours miss some docs and apps >> that >> kamailio already have. >> >> I'm asking from a a SER-user point of view, who want to migrate to SR-3 :( >> >> [1] http://ftp.iptel.org/pub/serctl/daily-snapshots/ >> [2] >> >> http://git.sip-router.org/cgi-bin/gitweb.cgi?p=ser;a=tree;f=ser_ctl;h=7db4a052064c6bd4ec2da6576c5a5ede4a0da2c0;hb=HEAD >> [3] http://cvs.berlios.de/viewvc/ser/serctl/ >> >> [4] http://ftp.iptel.org/pub/serweb/daily-snapshots/ >> [5] http://developer.berlios.de/projects/serweb/ >> >> Thank you, >> Claudio >> >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: ><http://lists.sip-router.org/pipermail/sr-users/attachments/20110526/f80c9d94/attachment-0001.htm> > >------------------------------ > >Message: 5 >Date: Thu, 26 May 2011 23:41:27 +0200 >From: I?aki Baz Castillo <i...@aliax.net> >Subject: Re: [SR-Users] [OT] IETF SIMPLE WG will destroy MSRP with the > new draft-ietf-simple-msrp-sessmatch-11 >To: mico...@gmail.com >Cc: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\) > - Users Mailing List" <sr-users@lists.sip-router.org> >Message-ID: <BANLkTimaCiruWVNmFebQui9KiKjRY=c...@mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >2011/5/26 Daniel-Constantin Mierla <mico...@gmail.com>: >>> I would not like to send a ISO image using RTP ;) >> >> That can be done with payload in sip messages. Again, you look only at a >> side of the coin, the one that is wrong, but gives you some reason to >> continue this debate -- I haven't said everything has to be RTP, so for >> example I mentioned TCP. > >Just to confirm: when you say TCP, do you mean SIP over TCP/TLS and >message data of file data within SIP messages body? Or do you mean >something like "RTP over TCP" for binary data transmission? (I'm 90% >sure you mean the first option, just want to confirm it). > > > > > >>> I really wonder how good is for kamailio having to deal with message >>> bodies of 1MB (being kamailio a SIP proxy, so theorically something >>> ready for handling small messages). >> >> This is your assumption. Besides that we talk about negotiation of a >> communication session, where parameter as agreed. The proxy can say in some >> cases when something is too big or too low (see registration time). > >When an audio/video session is negotiated, the SIP proxy does not >validate/constrain the "size" of the media. By passing the media (as >you suggest) through the signaling, such traffic is not end-to-end >anymore and intermediary proxies with no very good bandwitch (or >messages size constrains) would stand in the media traffic. > >Honestly I like the concept of "signalling through intermediaries and >media sessions end-to-end". > > > >>> 1) MSRP is not so new (2007). >>> 2) Your suggested new protocol would be newer than MSRP :) >> >> I suggested a new protocol? I have the impression that you read different >> content -- it is SIP, nothing else, just properly applied for particular >> cases. > >Ok, let me replace "new protocol" with "new spacefication" :) > > > >> Can you answer why presence is not on a different protocol >> (communication channel)? A presence document will all tags and extensions >> can easily go to quite significant size. > >Well, if we take into consideration XCAP stuff then SIP presence is >indeed a new protocol. But anyway you already know what I think about >SIMPLE presence specs. They are an IETF bug in all the terms (design, >scalability...). > > > >> You provide arguments I can't follow, jumping randomly -- so xmpp does IM in >> 'signaling', it is good because has session idea defined there (which is a >> simple concept as a 'string token' representing session id), > >Ok, I don't think XMPP is the very best protocol in the world. It >comes from many years ago (Jabber and so). I don't consider XMPP the >example to follow. > >Maybe SIP is the first protocol separating signalling and IM in >different streams. Maybe this is not the easiest approach to deal with >NAT/firewalls issues, but I like this radical concept. > > > >> while same >> concept in SIP (which exists for voice dialogs) will create a completely new >> protocol if applied for MESSAGE (let's not use MESSAGE, let's use UPDATE >> since it has the notion of session an can carry any kind body, is it >> better?). > >Right. I don't say that your approach is incorrect. In fact it seems >very suitable (but IMHO just for short text messages within a session, >not for file transfer). > > > >> You don't think that is bad in xmpp, but is bad in sip, because you >> _believe_ kamailio is able to work with small buffers only (would it be hard >> to increase them if needed? it will just relay, no understanding of >> content). > >Doesn't XMPP use gateways for file transfer?: > > >XEP-0095: Stream Initiation >------------------------------------------ >http://xmpp.org/extensions/xep-0095.html > >As the Jabber protocols are extended beyond basic messaging and >presence, the need has arisen for a generic protocol that can be used >to negotiate content streams between any two entities. Such streams >might be in-band, but more likely will be out-of-band, binary streams >used in applications such as file transfer, voice chat, and video >conferencing. This document provides a method for negotiating such >streams, including meta-information about the intended usage of the >stream. > > >XEP-0096: SI File Transfer >--------------------------------------- >http://xmpp.org/extensions/xep-0096.html > >This specification defines a profile of the XMPP stream initiation >extension for transferring files between two entities. The protocol >provides a modular framework that enables the exchange of information >about the file to be transferred as well as the negotiation of >parameters such as the transport to be used. > > > >If we take XMPP as an example, I think the above two XEP's seem more >similar to what MSRP defines. > > > > > >>> Well, IAX is much simpler than SIP, and IAX is basically the same you >>> are propossing (mixing signalling and media in the same stream). Do >>> you prefer IAX over SIP? :) >> >> And you cannot convince me in ages that MSRP is something bringing >> any benefits -- just another ugly hack for something that could have been >> solved very nicely with existing specs. > >Daniel, I could agree that using SIP message bodies for carrying IM >pure text/chat sessions could make sense, sure. But I don't think that >is also suitable for file transfer or any other kind of data. Even >less if we take into account that other IM protocols also use separate >streams for file transfer. > >MSRP just unifies IM sessions and file transfer in a separate stream. > > >Cheers. > > >-- >I?aki Baz Castillo ><i...@aliax.net> > > > >------------------------------ > >Message: 6 >Date: Fri, 27 May 2011 00:25:45 +0200 >From: Daniel-Constantin Mierla <mico...@gmail.com> >Subject: Re: [SR-Users] [OT] IETF SIMPLE WG will destroy MSRP with the > new draft-ietf-simple-msrp-sessmatch-11 >To: I?aki Baz Castillo <i...@aliax.net> >Cc: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\) > - Users Mailing List" <sr-users@lists.sip-router.org> >Message-ID: <4dded369.9090...@gmail.com> >Content-Type: text/plain; charset=UTF-8; format=flowed > > > >On 5/26/11 11:41 PM, I?aki Baz Castillo wrote: >> 2011/5/26 Daniel-Constantin Mierla<mico...@gmail.com>: >>>> I would not like to send a ISO image using RTP ;) >>> That can be done with payload in sip messages. Again, you look only at a >>> side of the coin, the one that is wrong, but gives you some reason to >>> continue this debate -- I haven't said everything has to be RTP, so for >>> example I mentioned TCP. >> Just to confirm: when you say TCP, do you mean SIP over TCP/TLS and >> message data of file data within SIP messages body? Or do you mean >> something like "RTP over TCP" for binary data transmission? (I'm 90% >> sure you mean the first option, just want to confirm it). >SIP over TCP with payload. > > >>>> I really wonder how good is for kamailio having to deal with message >>>> bodies of 1MB (being kamailio a SIP proxy, so theorically something >>>> ready for handling small messages). >>> This is your assumption. Besides that we talk about negotiation of a >>> communication session, where parameter as agreed. The proxy can say in some >>> cases when something is too big or too low (see registration time). >> When an audio/video session is negotiated, the SIP proxy does not >> validate/constrain the "size" of the media. > >Amazing, you found an example and it is again about voice/video! You >believe that SIP is only for those kind of communications. Btw, maybe >you know that rtp proxy can do re-sampling to avoid congestion. > > >> By passing the media (as >> you suggest) through the signaling, such traffic is not end-to-end >> anymore and intermediary proxies with no very good bandwitch (or >> messages size constrains) would stand in the media traffic. > >By initial design, sip is an end-to-end communication model. Forget >about record routing and see how the requests are flowing within dialog. > >> Honestly I like the concept of "signalling through intermediaries and >> media sessions end-to-end". > >What keeps me to have a session negotiation of MESSAGE requests to be >sent from point A to point B? > >Again, I think you haven't understood my point. MSRP defines a new >protocol, that is barely different than SIP. From MSRP RFC, here is the >very basic example: > > MSRP a786hjs2 SEND > To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp > From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp > Message-ID: 87652491 > Byte-Range: 1-25/25 > Content-Type: text/plain > > Hey Bob, are you there? > -------a786hjs2$ > > MSRP a786hjs2 200 OK > To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp > From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp > -------a786hjs2$ > > >What is the benefit over all, just a bit fewer headers, but more or less the >same format as SIP messages. >Maybe it saves a bit of bandwidth (hey there is SIP compession for that :-) ), >but then new points of failure >are added in the core network unnecessary. Such nodes need to keep states, if >they crash communication drops >(like with rtp relays). It is not the case with pure sip. > >I just looked quickly to some of msrp rfcs, it is practically yet >another sip-like protocol: they defiles paths set for the case of >many msrp relays (would that be like record-routing mechanism -- don't >take it literally and come back to me saying r-r has >a different purpose for audio sessions), authentication with digest, >a.s.o. Really funny!! > >I am more sure now that is really poor solution, no benefits, no >effective gain. > >It is time to stop here with the discussion, you loop back with out of >the context examples and I don't think you got my idea: session is >negotiated with invite-200ok-ack. The content is carried via SIP >(end-to-end or relayed through intermediate node when necessary) and >session terminated with bye-200ok. Simple as that -- when relay is >necessary, a sip proxy can do really good job in terms of performances, >no need to reinvent the wheel and have different applications in the >network. > >Cheers, >Daniel > >[...] > >-- >Daniel-Constantin Mierla -- http://www.asipto.com >http://linkedin.com/in/miconda -- http://twitter.com/miconda > > > > >------------------------------ > >_______________________________________________ >sr-users mailing list >sr-users@lists.sip-router.org >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > >End of sr-users Digest, Vol 72, Issue 67 >**************************************** _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
