o Max Mühlbronner on 07/19/2011 03:01 PM:
Hi,
sorry, my message was a bit out of context. Let me explain.
I dont need this yet, but also noticed there is was no support for
register requests. And imho a sbc should be able to handle Register
Requests, e.g. to forward Requests to the Registrar Server on the
inside network. At least this is one of the points described in
rfc5853 right?
For example, sbc would be located on the border of two networks and
should be the only SIP entry point to connect from the outside WAN. In
this Scenario a registration to the Proxy and outbound routing to the
SBC might be okay.. But does it really make sense? I would prefer to
keep everything internal and only expose the SBC to the outside.
yes, no and yes.
I'm just not sure about the benefit of all combined into one
proxy/b2bua hybrid versus a *separate* edge proxy instance (e.g.
implemented with sip-router) plus a separate B2BUA (implemented with
SEMS). Many of the edge proxy tasks (NAT ping, some DOS protection
etc) don't need a dialog stateful component, they can be perfectly
implemented transaction stateful or even stateless, e.g. REGISTER
handling.
The only drawback I see with such a setup is the extra route appearing
in calls on the outside, which I think should really be a minor issue.
That's why I was asking what scenario/functionality would be
implemented in the SBC regarding registration, to determine whether it
makes sense to add that into SEMS. Of course simple forwarding and
rewriting of REGISTER requests is pretty simple to implement.
Stefan
--
frafos.com
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
