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

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

Below...

> 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.

No: if service retargeting is used, and History-Info is used,
the History-Info will record the service retarget as well.

That being said:

- They will not necessarily match. Most "retargets" in SIP
  are 302 ("Moved"). It says nothing about the reason (Busy,
  Always, etc.). 

- You will therefore end-up with a whole bunch of 302s in 
  history-info, which are pretty much useless for explicit
  service retargeting.

- Even a gateway with infinite intelligence will not be
  able to parse all the History-Info to try to figure out
  what is the intent. All it will see is that the call was
  retarget a gazillion times, for various SIP reasons, completely
  irrelevant to the desired treatment.

- Furthermore, History-Info depends on the "network" supporting
  it. Retargeting a service doesn't require any new extensions
  on the proxy "in the middle". service-retargeting is just
  plain retargeting.

> > 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.

This is an artifact of the way many services (like voicemail) work
in practical network. 

In my mind, the "redirection-reason" is really a service request. It
happens to "look" like a historical record, but really, it is not. It
is really a carefully chosen reason than can easily be mapped to
existing practice.

> > 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.

Yes, that's the whole. You spoon feed the application so that
you don't get ambiguous service requests.

What really scares me is the alternative. In order to make 
History-Info work with, say, a voicemail service without using
explicit service retargeting, the only alternative is to 
have somebody (i.e., the network) muck around with History-Info,
removing extraneous entries (like redirect server routing, 
name to phone-number retargets, etc.). The status quo will encourage
people to "falsify" history-info, which is a very scary prospect.

Another example of falsification is when the redirection happened
in the PSTN. The last thing I want is for people to create "fake"
History-Info. 

A service-retarting URI makes perfect sense in this case because
PSTN uses "Redirecting reason" as a service invocation. A GW could
therefore "map it" to a service URI. This would then be transparent
to a network that can then route it transparently to the SIP VM system.
Nobody is hurt...

> > 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?

It's in the URI. A GW that supports service retargeting would add it.
But it poses no additional requirement on the infrastructure (i.e., 
SIP proxies).

> > 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.

I would think that if your VM system is native SIP, and your
phones are also SIP, it probably makes more sense to use the
more explicit "Deposit"-like mechanism like in RFC 3087. I agree.

It is really when at least one side (either the phone/gw or the
SIP VM system/application) is restricted to a legacy "redirect
reason" feature invocation code that I would use service-retargeting.


> > 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.

Good. Thanks.

_______________________________________________
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