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. 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. 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. > >> >> 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
