[SR-Users] sr-users Digest, Vol 72, Issue 67

[Boris]

sr-users-request at lists.sip-router.org wrote:

>Send sr-users mailing list submissions to
>	sr-users at 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-request at lists.sip-router.org
>
>You can reach the person managing the list at
>	sr-users-owner at 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." <david at 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 at lists.sip-router.org>
>Message-ID: <4DDE9BAB.4060401 at 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 18005551212 at mydomain.com alias to 1001 at 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.
>
>18005551213 at mydomain.com alias to 1800555124 at 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 <jan at ryngle.com>
>Subject: Re: [SR-Users] Green VoIP - energy efficiency and
>	performances of	v3.0
>To: miconda at gmail.com
>Cc: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\)
>	- Users	Mailing List" <sr-users at lists.sip-router.org>,	sr-dev
>	<sr-dev at lists.sip-router.org>
>Message-ID: <BANLkTikUb_iwBDEuqk977-ECmmHo4dEXvQ at 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
><miconda at 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<jeremy at 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 at 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 at 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 <miconda at gmail.com>
>Subject: [SR-Users] Kamailio v3.1.4 Released
>To: kamailio <sr-users at lists.sip-router.org>, 	sr-dev
>	<sr-dev at lists.sip-router.org>, business at lists.kamailio.org
>Message-ID: <4DDEA35A.7070606 at 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 <elcaio at gmail.com>
>Subject: Re: [SR-Users] ser_ctl / serweb
>To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
>	Users	Mailing List" <sr-users at lists.sip-router.org>
>Message-ID: <BANLkTik+dnTp-egK2xy1ua=tPnCcaDuuOA at 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 <elcaio at 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 <ibc at aliax.net>
>Subject: Re: [SR-Users] [OT] IETF SIMPLE WG will destroy MSRP with the
>	new	draft-ietf-simple-msrp-sessmatch-11
>To: miconda at gmail.com
>Cc: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\)
>	- Users	Mailing List" <sr-users at lists.sip-router.org>
>Message-ID: <BANLkTimaCiruWVNmFebQui9KiKjRY=c1Yg at mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>2011/5/26 Daniel-Constantin Mierla <miconda at 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
><ibc at aliax.net>
>
>
>
>------------------------------
>
>Message: 6
>Date: Fri, 27 May 2011 00:25:45 +0200
>From: Daniel-Constantin Mierla <miconda at 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 <ibc at aliax.net>
>Cc: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\)
>	- Users	Mailing List" <sr-users at lists.sip-router.org>
>Message-ID: <4DDED369.9090409 at 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<miconda at 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 at lists.sip-router.org
>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>End of sr-users Digest, Vol 72, Issue 67
>****************************************