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

From: "Francois Audet" <[email-masked]>
Date: Thu, 13 Oct 2005 21:22:55 -0500

No, you didn't summarize it correctly.

History-Info provides a record of retargeting that has already happened 
to a request. 

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.

It is NOT true that the information carried in History-Info and in the
service URI will be identical. 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. 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.

If you look at RFC 3087's example, one may use something like 
sip:+14085551212@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:+14085551212@wcom;old-target=+155555510002;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).

> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[email-masked]] 
> 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dean Willis <[email-masked]>
Date: Fri, 14 Oct 2005 16:51:00 -0500

> so we could do interoperable products.

So how does this relate to draft-burger-sipping-netann-11, which  
provides mechanisms for forward-encoding of standard imperatives into  
the request URI in accordance with RFC 3087?

--
Dean