I want to completely replace my SBCs with OpenSER boxes :) I don't need them, other than the fact that they provide me with a bit of fail over and redundancy with regards to media streams and call state if I ever happen to lose an entire box for some reason. Oddly enough that seems to happen often with my SBCs (go figure) and hasn't happened once yet with my registrars (my OpenSER boxes)
OpenSER it just fine at doing everything else. -Daniel On Aug 3, 2007, at 6:45 AM, Daniel-Constantin Mierla wrote: > > > 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. >> ____________________________________________________________ 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
