RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

["Francois Audet" <[e-mail]>]

> But I don't see it as roughly equivalent to the serice-URI 
> proposal -- if the service-specific URI information is really 
> 3087-compliant, (as Francois seems to intend) History+hack is 
> not at all equivalent. History
> +hack is, however, a thorough replacement for Diversion. You 
> could build
> applications that would look much the same to the end user 
> using History
> +hack as you could with service-URI, but the composition logic is
> entirely different.

I agree.

History+Ack reflects only what has happened at SIP level.

Diversion and service-URI may be used to reflect things that happen 
not at SIP level (e.g., PSTN).

> > This really brings us back to the debate we've had in this 
> area from 
> > day one as to where the service logic is - in the network 
> or relegated 
> > to some end application server or user.  Basically, we're debating 
> > whether the redirect server should provide the appropriate service 
> > specific URIs or whether we put the burden on the end 
> application to 
> > decipher the H-I entries.  It's  been suggested that the latter is 
> > quite difficult, however, I think that can be debated. I 
> agree it does 
> > but an additional burden on the recipient applications and that 
> > overall IF the service specific URIs are agreed and appropriately 
> > configured, it is a much simpler solution in terms of 
> processing for 
> > the end application.
> 
> Yes, that is the real heart of the question. As I said, I 
> believe I'm agreeing with what I think Francois is saying 
> about service-URIs, but I also think History-Info gives us 
> more capabilities than we seem to be realizing in this discussion.

Good.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP