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

["Michael Hammer \(mhammer\)" <[e-mail]>]

Francois,

Inline. 

> -----Original Message-----
> From: Francois Audet [mailto:[e-mail]] 
> Sent: Thursday, October 13, 2005 10:23 PM
> To: Michael Hammer (mhammer); sipping
> Cc: Elwell, John
> Subject: RE: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> No, you didn't summarize it correctly.
> 
> History-Info provides a record of retargeting that has 
> already happened to a request. 

Are you saying that if History-Info is used and these headers are
included in the Request URI, that the value contained in the
"old-target=" parameter will not appear in the History-Info header?
Does it require one more hop before this information is moved from R-URI
to History-Info?  Perhaps I misunderstood the timing of the insertions.

> draft-elwell-sipping-service-retargeting provides EXPLICIT 
> service invocation, in exactly the same way RFC 3087 does. 
> The only difference with RFC 3087 is that the URI parameters 
> in RFC 3087 are abstract "examples", while we would like the 
> parameters to be well-known so we could do interoperable products.

RFC 3087 appears to provide a keyword requesting a type of service to be
invoked, while service-retargeting has redirecting-reason codes that
simply say what state was encounted, and is no different than the Reason
header using Q.850 codes or Q.732 if need be.  If it quacks like a duck,
waddles like a duck, ... don't tell me it is a swan.

> It is NOT true that the information carried in History-Info 
> and in the service URI will be identical. 

Please re-read my words carefully.  I said "can have identical
information".  That means that the same value can appear in both places
in the message.  I did not say that everything in the History-Info would
appear in the Request-URI.  But, I take your point that putting this in
the R-URI would spoon-feed the application.

> History-Info 
> records everything, even what is absolutely of no relevance 
> to the application (e.g., routing by a Redirect Server, 
> changing an email-looking address to a phone-number looking 
> address, etc.). The application has no way of knowing what is 
> relevant and what is not. In this particular example, 
> History-Info records too much. History-Info is also optional, 
> and you depend on somebody else's goodwill to make the 
> application work. 

Won't this new parameter also be optional?

> In this particular example, it records too 
> little. Finaly, History-Info records the SIP retarget reason 
> (i.e., 302 in most cases), while this proposal uses the 
> "logical" service being accessed.

This seems to get closer to the crux of the issue, which is that most
SIP devices will likely use the less informative SIP codes than the
lengthier list of cause codes accumulated in the PSTN.  This mechanism
attempts to introduce them as more native to SIP rather than inherited
indirectly.  But, I would find the argument more persuasive if there
were service actions like your "deposit..." below that are EXPLICIT as
you point out above, than the passive "busy" encountered that is
actually used.

> If you look at RFC 3087's example, one may use something like 
> sip:[phone]@wcom;mode=deposit-when-busy to "deposit" a message. 
> RFC 3087 doesn't actually define the "mode" parameter, as a 
> side note, which means that "magically" you need to 
> coordinate the retargeting entities with the application to 
> understand what it means.
> 
> We would like to use something like
> sip:[phone]@wcom;old-target=[phone];retargeting-reason=busy
> 
> To me, this is already legal in RFC 3087. We are simply 
> trying to agree on values for the cases that are very 
> difficult to interwork in real life situations today, because 
> of the vagueness of 3087, in particular in scenarios dealing 
> with PSTN interop (and other scenarios I described earlier).

BTW, I support the motivation for this work and the need to ensure
services work, one way or another.  We just need to make decisions with
full awareness of the tradeoffs.

Mike


> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[e-mail]]
> > Sent: Thursday, October 13, 2005 12:34
> > To: Audet, Francois [SC100:9T51:EXCH]; sipping
> > Cc: Elwell, John
> > Subject: RE: [Sipping] Re: 
> > draft-elwell-sipping-service-retargeting-00.txt
> > 
> > 
> > Francois,
> > 
> > The draft is compared with History-Info because service-retargeting 
> > proposes parameters that can have
> > *identical* information.  Both are *not* derived information. 
> >  If the proposed parameters were more like RFC 3087, we would be 
> > having that comparison discussion.
> > 
> > So, are you are proposing that service-retargeting drop information 
> > identical to History-Info and using something along the lines of a 
> > standardized "service=" parameter with values along the 
> lines of RFC 
> > 3087?
> > 
> > Did I summarize your view correctly?
> > 
> > Mike
> 

_______________________________________________
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