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

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

On Fri, 11 May 2007 08:14:51 +0200
"Christer Holmberg \(JO/LMF\)" <christer.holmberg at ericsson.com> wrote:

> One needs to remember that routing towards the correct intermediates is
> only one step. You also need to to be able to route the request towards
> terminals which support the service.

From a Service Oriented Architecture point of view -- No, you don't.
What we need to do is to be able to route the request towards the
terminals which have the capabilities required by the service. 

That's a VERY different problem.

Otherwise you get into this exponential race condition of all the nodes
having to agree to all the "service names" and there's very little hope
of anything actually being introducable ever again.


 
> >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.
> 
> Based on the assumption that Bob knows that he has to invoke a recorder
> in the first place (maybe he knows that in this specific example), that
> Bob knows has the URI of the recorder (and possible all other
> intermediates that need to be inserted), and that Bob knows where and in
> which order to put the URI(s) in the pre-Route (there can also be other
> pre-Route headers in the request).

Or (and that's why I used INVITE instead of REFER) Bob's proxy (based on 
perhaps web-controlled policy) could retarget Bob's INVITE through the 
recorder. This way Bob's UA doesn't even have to know about the service.
 
> I also think it's important to remember that RFC3261 allows a proxy to
> forward requests pretty much based on ANY information (DNS lookups,
> databases, signalling information etc etc), so I think it would unfair
> to say that such behavior would "break" SIP as a protocol (no, I didn't
> say that someone has said it as part of this thread).

right.

--
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