[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] I-D on service identification now available
Hum, interesting. I like the concept, but...
A few questions:
1) Wouldn't this cause some backward compatibility problems? Won't some
proxies choke on
URNs in a Route header? Or are you making the assumption that you
have to ensure that the
Route entry is the first one in the list (i.e., the outbound proxy)?
I'm assuming that's
the assumption.
2) Couldn't we just load
sip:record-service.store=y.format=g711 at recording-server.orig-domain.com
directly in the client??? When the client is provisioned, it would
equate
"Call-Recorder-Service" to
"sip:record-service.store=y.format=g711 at recording-server.orig-
domain.com"? I'm not sure I see a huge advantage in having the
Outbound proxy do
the substitution versus the client doing it. Especially if automatic
provisioning
is used (Config-framework for example).
3) Why do you want to document it "elsewhere"?
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen at cisco.com]
> Sent: Friday, May 11, 2007 10:06
> To: Dean Willis
> Cc: Markus.Isomaki at nokia.com; sipping at ietf.org; Christer
> Holmberg (JO/LMF)
> Subject: Re: [Sipping] I-D on service identification now available
>
> 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-d
> omain.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
>
_______________________________________________
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