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

[Jonathan Rosenberg <jdrosen at cisco.com>]

What the previous version of the draft proposed, and what I still think 
makes sense, but should be documented elsewhere, is to do something like 
this. The phone, wanting a recording service, would emit a request that 
looks like:

INVITE sip:called-party at target-domain.com
From: sip:caling-party at orig-domain.com
Route: urn:service:call-recorder

when this arrives at the outbound proxy in the originating domain, that 
proxy would basically translate this URN to a URI for a recording 
service that it knows about:

INVITE sip:called-party at target-domain.com
From: sip:calling-party at orig-domain.com
Route: 
sip:record-service.store=y.format=g711 at recording-server.orig-domain.com

and then it happily goes there.

-Jonathan R.

Dean Willis wrote:

> 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

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen at cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
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