Subject: RE: [Sipping-tispan] RE: Voicemail-uri draft

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Thu, 17 Nov 2005 15:28:06 +0100

So we agree if nothing is done there will be confusion as to why retargeting occured. 

What I am saying is that there is a clear requirement to be able to identify that retargeting was triggered by Call Forwarding service.

This requirement can be fullfilled in several ways but since we are looking at voicemail-URI-draft, the most simple way is not to add a history-info in case of "Call forwarding retargeting".

A consequence since we do not have the explicit list of "forwarding-targets" (we only need the original called party and the lattest redirecting party), we will need a call forwarding counter.

   sebastien

-----Message d'origine-----
De : Paul Kyzivat [mailto:[email-masked]] 
Envoyé : jeudi 17 novembre 2005 15:02
À : GARCIN Sebastien RD-CORE-ISS
Cc : Elwell, John; Francois Audet; Cullen Jennings; [email-masked]
Objet : Re: [Sipping-tispan] RE: Voicemail-uri draft

GARCIN Sebastien RD-CORE-ISS wrote:

> [SG: Yes the trick, however there is not justification to use "SIP 
> response codes" instead of explicit diversion reasons.]

The problem I am having with explicit diversion reason codes is that they are only well defined in a particular implementation, where there is a very specific set of services that affect how a call is processed. 
A sip implementation that doesn't work that way may not be able to map its reasons for doing things onto that namespace.

> For multiple retargets, or cases where normal SIP routing overwrites the Request-URI, it will be necessary to use History-Info to extract the retargeting information. This was true also of the service-retargeting draft.
> 
> [SG: See my answer to Paul, "general retargeting" and "Call 
> Forwarding" retargeting are no identical. Having a list of 
> history-info entries does not mean that the call encountered several 
> call forwarding service invocations. This is why I still think we need 
> a call fowarding counter.]

This is an example of my point above. I don't find any meaningful difference between "call forwarding" and 800-number translation. They are both retargetting of by an entity responsible for an address to a different address. I guess some think of this as two distinct features, but I see no intrisic way to distinguish one from the other.

	Paul

_______________________________________________
Sipping-tispan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Nov 2005 10:10:31 -0500

> So we agree if nothing is done there will be confusion as to why retargeting occured. 

I will go further, and say that even if something *is* done there will 
still be confusion about why retargetting occurred. There are an 
infinity of potential reasons for retargetting.

I guess the TISPAN goal is to classify all retargetting reasons into 
some small number of buckets. In principle I guess that is possible, as 
long as one of those buckets is "other".

AFAIK, TISPAN is proposing a set of reasons based on a belief that there 
are a small number of defined "features" that might cause retargetting, 
and so each feature can be considered a "reason". Presumably this can 
work across multiple technologies, of which sip is only one, as long as 
all agree that these are the only kinds of retargetting there are.

Many in the sip community envision a richer, unbounded, set of services, 
and don't intend to standardize them. So it is proposed that the sip 
response codes be used to categorize why retargetting has been done. 
This provides a larger set of categories. And within limits it can work 
regardless of what services you implement. But of course it is only 
directly meaningful when using sip. When gatewaying between protocols 
there will be a need to translate. Because the categories aren't 
isomorphic, there will be information loss in some cases.

The suggestions to add more sip response codes is intended to help with 
this problem. It can potentially ensure that every TISPAN retargetting 
reason maps to a unique sip response code, so there is no loss of 
information going in that direction. Because there are more sip response 
codes there will still be information loss going from sip to tispan 
reasons. But nobody seems to be obsessing over that.

> What I am saying is that there is a clear requirement to be able to identify that retargeting was triggered by Call Forwarding service.

If this is truly what you mean, then you only want this identification 
present when the call is retargetted by a component that implements a 
TISPAN approved Call Forwarding service? So if instead it is retargetted 
by a SIP PBX that never heard of TISPAN then this is not something you 
care about?

	Paul