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

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Fri, 18 Nov 2005 10:04:16 +0100

See below

sebastien 

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

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: If the proxy or UA simply does retargeting in the broader sense then it should follow the history-info framework. Otherwise if it is performing a call forwarding service it will be aware a user service profile and can and should be more specific.]

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

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

[SG: The "reason" for retargetting which we are talking about is in order to offer a "service" so yes this is distinct from a SIP 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.]

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: Exactly yes, that's because the general retargetting framework already exists in SIP (it's history-info) what TISPAN needs is a service specific framework.]

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

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?

[SG: Yes, I would propably be able to pass a basic call but I might not be able to interoperate the actual services]

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

[SG: If it's you SIP office system that does the forwarding then yes I might not want to get the indication that corresponds to a busy condition in my TISPAN network because I cannot be sure of what happened via SIP signalling. ]

	Paul

> 	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: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 22 Nov 2005 21:23:45 -0500

Having caught up with this discussion, I have an impression that what is 
needed for service emulation is some sort of "P-Service-History:" header 
field.  I propose a P-header because the meaning of the entries would be 
network-specific.  After all, defined services are offered on a network 
basis.  You can read "federation of networks" if you want.

Anyway, the header field would contain a record of services performed 
and any other information such as where they were performed that would 
provide a complete accounting.

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 30 Nov 2005 13:50:58 -0500

I'm just getting caught up after IETF, so I've read the last few weeks
of messages on this topic in a bloc.  I don't know if I have missed some
critical background, but I am brought to several observations that
suggest that this problem isn't as difficult as the current discussion
suggests.

- People from the PSTN should beware that dividing network activities
into a small number of defined "services" is very unnatural from the
IETF point of view.  So when dealing with a situation where this
conception is essential to understanding, that a "services" architecture
is involved should be made very explicit at the beginning.

- There is no need for an additional "forwarding counter", as long as
the goal is only to prevent infinite forwarding loops.  As long as
forwarding is done in the manner of a SIP proxy, there is already the
"Max-Forwards" header to perform this function.  For forwarding done by
a B2BUA, it should ensure that the Max-Forwards on any request it
generates is less than the Max-Forwards on the request it received --
but that is needed in general to prevent B2BUA's from creating infinite
loops; it is not a new requirement.

I suppose that there might be a problem if (for example) a call is
forwarded by a SIP agent, then routed to a PSTN network, forwarded
within the PSTN network, and goes back to a SIP network; we must ensure
that the Max-Forwards generated upon that second entry to a SIP network
is smaller than the Max-Forwards of the original SIP request.  But that
is solved by the fact that we must anyway be decrementing the Max-
Forwards that is generated when a request is passed from the PSTN to a
SIP network based on the number of PSTN forwarding events the request
has encountered, in order to ensure that calls that transition between
the PSTN and SIP multiple times can't loop.  Again, this is not a new
problem for call redirection per se.

- The "response codes" vs. "service reason" seems to be less serious
than people are making it out to be.  As people describe it, the
History-Info headers seem carry enough information -- what the request-
URI was, what the new request-URI is, and a SIP response code used as a
service reason.

There are design issues when deciding whether to combine two similar but
not identical namespaces into one, but I will not reopen that question,
as it seems to have been settled at IETF 64.

To ensure that PSTN -> SIP -> PSTN routes do not lose information, each
TISPAN service reason needs to be mapped to a distinct SIP response
code, which may require defining some new response codes.  But nobody
seems to have a problem with that.  And if we start exhausting the
number space, we can allocate some (e.g.) 7xx response codes, since
these service reasons will never appear as true SIP response codes.

There seems to be a question of whether any of the "service reason"
response codes should be the same as any existing response code.  E.g.,
is "Call Forward on Busy" the same as "call redirected due to a 486
response"?  But that seems to me to be a TISPAN problem -- If TISPAN
wants a separate code for Call Forward on Busy, it will be documented as
such, and anyone who wants to consider CFB as the same as 486 will be
able to do so easily enough.

There will be a problem when going from SIP to PSTN, in that the
universe of SIP response codes will have to be compressed into a smaller
set of service reasons.  But the PSTN must (explicitly or implicitly)
already have a policy on how to handle an unknown service reason; there
is effectively an "other" category of some sort.  The only truly open
question is whether 486 will be conflated with CFB upon entering the
PSTN, or turned into "other".  But again, that's a TISPAN problem, based
on exactly what the CFB service reason means in the PSTN.

My apologies for any misunderstanding on my part.  But I think that this
at least summarizes the current issues and may help people to come to a
speedy resolution.

Dale