FreeSWITCH, since it is a B2BUA, can be deployed as an SBC (Session Border Controller). I understand that SBC itself is a fairly complicated product and needs to be more security oriented rather than application oriented. For this reason many proprietary SBCs are sold and deployed all over the world. However, most of the things they claim accomplish can already be done in FS, such as SIP header or SDP manipulation/normalization, transcoding, hide topology, limit sessions and calls, etc. This thread is mainly to discuss some of the non-obvious things which other SBCs might have implemented and users would like to replicate using FS. A couple days ago I was working with a carrier which said they ignore OPTIONS and REGISTER packets. Is there somehow we can do the same in FS? This would be beneficial to carrier-type users who only do wholesale traffic from trusted IPs and do not want to mix user registration in it. I don't know why they would ignore OPTIONS. The first solution that comes to my mind is to block all IPs and allow only trusted IPs. This cuts down on the REGISTER attempts from untrusted IPs, but does not deal with the OPTIONS (or even REGISTER) packets from trusted IPs. A proprietary SBC my company is evaluating these days, the name of the provider or the product I would prefer not to mention, has the ability to forward REGISTER packets. A few days ago I saw in the FS mailing list archive (http://old.nabble.com/FreeSWITCH-as-pure-SIP-proxy-td20096367.html) that FS, being a B2BUA, does not simply forward REGISTER packets. Instead, it consumes them by either deeming them to be valid and registering user or rejecting them. From the standpoint of an SBC, it should simply be routing the packet rather than consuming it; basically act as a proxy for REGISTER packets only. Has anything changed? Is there anything you guys have done, something non-obvious, that could be used to implement FS as an SBC? Please share. Thanks.