Wow, thanks for sharing. I honestly didn't know about that one! Joel Gerber Network Specialist Network Operations Eastlink E: joel.ger...@corp.eastlink.ca T: 519.786.1241
-----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kap...@oracle.com] Sent: July-18-13 1:48 PM To: Joel Gerber Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] RTP flow's route follows SIP flow's route ... There kinda sorta is one, in RFC 5853: http://tools.ietf.org/html/rfc5853 Obviously it's not complete/comprehensive, though. But yeah basically "SBC" is an industry market term, and it's muddy... not a formal definition like RFC 3261 "Proxy". -hadriel On Jul 18, 2013, at 11:22 AM, Joel Gerber <joel.ger...@corp.eastlink.ca> wrote: > SBC is a rather arbitrary term referring to a bunch of different functions. > Typically an SBC is a B2BUA, RTP media-proxy, stateful firewall, QoS/policer, > NAT traverser and a transcoder, but this is not always the case. Some vendors > stick on the name SBC, and it just performs SIP ALG functionality. > > I typically just call them B2BUAs, and will specify whether they have > additional functionality, because the term SBC really doesn't mean anything > when there is no standard as to what functionality a device needs to support > in order to earn the name. > > SBCs typically follow a bunch of separate standards, without implementing any > "magic" outside of what a certain standard allows. IE: In RFC 3261, there is > no mandate on what a B2BUA has to do when it translates signals from a dialog > facing one endpoint to a dialog facing another. Removing/Adding/Changing > header values is both allowed, and maybe even expected. > > Joel Gerber > Network Specialist > Network Operations > Eastlink > E: joel.ger...@corp.eastlink.ca T: 519.786.1241 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
