Re: [Sipping] I-D on service identification now available

[Dean Willis <dean.willis at softarmor.com>]

On Thu, 10 May 2007 13:12:55 +0300
<Markus.Isomaki at nokia.com> wrote:


> It may be that even in these cases the model where the "originating" SIP
> provider tries to determine what to do based on inspecting the SIP
> message may not be the right one. It would be better if we had a
> mechanism whereby the UAC/user could request something like "recorder"
> or "front-end mixer" to be included in the session (presumably these are
> implemented as B2BUAs). Jonathan once had a proposal to use Service URN
> to address these type of services. Perhaps it would be enough to use
> just SIP URIs also here. Is it possible to "chain" these in your session
> using e.g. pre-loaded Route? All in all this seems a bit complicated in
> practice...

I think you're headed in the right direction here.

Rather than having the service invocation be an implicit side-effect of 
analyzing the signaling, I'd much rather have the invocation be explicit.

Pre-loaded routes give us a reasonable way to do proxy services.

In cases where the services are implemented as B2BUAs, we don't need that
sort of complexity.

If Alice is calling Bob and wants to invoke a recorder for the call, Alice
could send her initial request to the recorder-B2BUA, along with whatever
parameters are needed (file format, location, billing account, etc.) and
a URI to be used for Bob.

This takes all of the silly guessing games and requirements for "service
identifiers agreed to by all providers" right out of the equation.

--
dean


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP