On Fri, Jan 28, 2011 at 3:59 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
I have described this in the past as a case in which the webserver is the signal path, but your description of "signaling intermediation" sounds more ambitious. In particular, do you mean that it might use different syntax with different clients, using this shared semantics?
That's one possibility. It might also do a similar function to what I think the SIP SBC does, and do address rewriting, stop stuff it doesn't like, or generally do like gateways do (that is, whatever it wants to). But as long as that behaviour doesn't have to be described in the spec to make things work, I think it should be outside of the scope of the working group.
I think a core scope question, then, is how complete the APIs to control the behavior of the web-server-as-intermediary need to be? If the working group expects the web server to act as session border controller, do those semantics (especially for QoS and security) get exposed and described by the WG? best regards, Ted Hardie