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

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

Paul,

More discussion in-line 

Regards,
sebastien

-----Message d'origine-----
De : Paul Kyzivat [mailto:[email-masked]] 
Envoyé : jeudi 17 novembre 2005 16:11
À : 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:
> 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.

[SG: If we can at least capture the legacy "Call forwarding" ones properly, I'll be happy. If there are other retargetting reasons that need to be explicitly stated then that's fine.]

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

[SG: There is no classification to be done, legacy actors such as ITU-T, TISPAN and 3GPP want to be able reproduce a Call Forwarding Service (we use the word "simulation"). I don't have a problem in adding the value "other" to the already identified CF reasons.]

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.

[SG: Yes, currently H.323 (with H.450 series) and BICC are examples of IP-based call control protocol that support exactly those legacy Call Forwarding reasons.] 

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.

[SG: In my view, it perfectly ok to add a Reason header with "SIP status" code indicating that the receipt of such SIP response was the reason for retargeting but this should only apply to cases where such SIP response were effectively received. However what we really is a service reason not a protocol reason.] 

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.

[SG: The mapping provided in the voicemail-uri actually works fine with the existing SIP response code (in a bijective manner I mean). The question really is are we sure that this mapping should be done ??? If I cannot be sure that such  retargeting was not triggered by a Call Forwarding service I will not consider this mapping a good idea.]

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

[SG: Yes approved by ETSI + T1S1 + ITU-T + 3GPP . The whole idea of having SIP standardized in IETF is that even a SIP PBX that chooses to ignore all above bodies will use the same mechanism.]  

	Paul

> 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 14:04:35 -0500

> [SG: There is no classification to be done, legacy actors such as ITU-T, TISPAN and 3GPP want to be able reproduce a Call Forwarding Service (we use the word "simulation"). I don't have a problem i…

There is no classification to be done if you are coming from a source 
that starts out with them classified that way. But if you have a sip 
proxy or UA that is retargetting, then it must classify what it is doing 
into one of the categories.

If it is doing retargetting because it received an error response to a 
sip message, and the sip response codes are being used as reasons then 
this is straightforward. Otherwise it requires some decisions. More below.

> [SG: In my view, it perfectly ok to add a Reason header with "SIP status" code indicating that the receipt of such SIP response was the reason for retargeting but this should only apply to cases wh…

So you are suggesting that retargetting based on a sip reason is always 
distinct from retargetting based on a tispan reason?

> [SG: The mapping provided in the voicemail-uri actually works fine with the existing SIP response code (in a bijective manner I mean). The question really is are we sure that this mapping should be…

I don't understand you here. Are you saying that you need to distinguish 
a sip reason code of 486 that means "this call was forwarded because I 
received a 486 Busy response from the original target" from a sip reason 
code of 486 that means "this call was forwarded by the Call Forward Busy 
service"???

> [SG: Yes approved by ETSI + T1S1 + ITU-T + 3GPP . The whole idea of having SIP standardized in IETF is that even a SIP PBX that chooses to ignore all above bodies will use the same mechanism.]  

This is a surprise to me!

Do you not expect to interoperate with other sip domains, that don't 
have the same precise service definitions?

So if my SIP office system is connected up via some kind of peering 
relationship so that it can call subscribers of a tispan network, and it 
does sometimes forward calls when it gets busy responses, but it doesn't 
formally have a TISPAN certified Call Forward Busy service, then you 
don't want to get the indication that corresponds to your Call Forward 
Busy???

	Paul