On 08/03/07 12:38, Daniel Corbe wrote: > See below. > > -Daniel > > On Aug 3, 2007, at 5:04 AM, Daniel-Constantin Mierla wrote: > >> >> On 08/02/07 20:04, Daniel Corbe wrote: >>> Out of curiosity are you affiliated with the OpenSER project? >> yes, I am, very deep involved actually, from its beginning. >>> If so does OpenSER support SCTP? >> It does, since few days ago. It came as a contribution from >> Connecticut College, I reviewed and integrated in OpenSER and did the >> initial testings. >>> Is that why you need a phone that runs over SCTP? >> Yes. In fact, other SIP entity with SCTP support is fine (of course, >> at a low cost). I would like to test with other implementation, you >> know, interoperability in VoIP/SIP was all the time a pain in the ... >>> >>> What's the purpose if you have other more reliable transport >>> mechanisms for SIP such as TCP? >> TCP brings a lot of overhead, it is one-to-one communication model, >> while with SCTP you get one to many, as with UDP. For SIP servers >> able to support large number of online subscribers, TCP reduce the >> capacity a lot. Also, for NAT, TCP is problematic if the phone does >> not maintain the connection open, it is basically impossible to open >> the connection from server side. >> >> The problem I see with UDP is fragmentation and encryption. SCTP and >> TLS-SCTP overcome them. We face now big SIP messages, especially in >> IM&Presence extensions. > > There's many differing opinions on this issue. With things like > kqueue() and epoll() you can easily squeeze 50k or more simultaneous > connections onto a single server and have plenty of processing power > left over for things like TLS. More often than not its the higher > layers which are the bottleneck.
you are right, *poll methods increased a lot the TCP capacity. However, for a load balancer or traffic dispatcher working with TCP is a killer. The LB should be able to deal with more than 50k sessions. I do not know SCTP performances, it is first time I actually worked with, but from design seems to be a good choice. It is what I try to learn and why I am asking opinions here. > > I don't know how well SCTP performs under these sorts of loads but if > it performs better than TCP while providing some connection-oriented > services that UDP doesn't, more power to you. From my chair here; > though, SCTP would have to support bindings into the 100K range per > box or more before I would consider it a viable option over UDP. One other thing that it is not clear for me, is the NAT traversal, haven't seen many SOHO routers advertising SCTP in product sheet, so there might be other issues arising when using SCTP at this time. > > Working on increasing the capacity of your service alone does little > good because then it becomes a gigantic single point of failure. I > would like to see more open source projects like OpenSER support full > signaling state redundancy between two boxes. Only then would I ever > consider shoving 100k bindings onto a single registrar. There are different aspects and cases when the capacity matters. Nobody (I hope) goes with hosting on single hardware huge number of subscribers, there are solutions for replication and fail over. However, we don't discuss that here, load balancers, dispatchers, SBCs need to be able to deal with far more many connections at same time than a registrar. Daniel > > >> >>> >>> AFAIK the only thing in heavy deployment in telephony that uses SCTP >>> is SIGTRAN and family. >> OK, so, then here is another question, do you think that SCTP won't >> make it to the end devices (e.g., phones)? > > I try not to make predictions because I'm wrong more than I'm right. > >> >> Cheers, >> Daniel >> >>> >>> -DAniel >>> >>> On Aug 2, 2007, at 12:30 PM, Daniel-Constantin Mierla wrote: >>> >>>> Hello, >>>> >>>> I couldn't find much about SIP phones with SCTP support. Are you aware >>>> of any? >>>> >>>> OpenSER introduced support for SCTP and for testing it was used: >>>> >>>> [udp] -------- [udp] openser [sctp] ------------ [sctp] openser [udp] >>>> ------------ [udp] >>>> >>>> But using against other devices is really the challenge. I found some >>>> references to a modified KPhone version, but no luck to get it. >>>> >>>> Thanks, >>>> Daniel >>>> >>>> -- >>>> http://www.openser.org >>>> >>>> _______________________________________________ >>>> Sip-implementors mailing list >>>> Sip-implementors@lists.cs.columbia.edu >>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>> >>> >>> ____________________________________________________________ >>> This e-mail (including attached documents) may contain confidential >>> or proprietary >>> information intended only for use by the named recipient(s). Use by >>> persons >>> other than the named recipient(s), further dissemination, or copying >>> of this >>> email is prohibited unless authorized by the sender. >>> > > > ____________________________________________________________ > This e-mail (including attached documents) may contain confidential or > proprietary > information intended only for use by the named recipient(s). Use by > persons > other than the named recipient(s), further dissemination, or copying > of this > email is prohibited unless authorized by the sender. > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
