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

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

Hi John,

See below,

sebastien

-----Message d'origine-----
De : Elwell, John [mailto:[email-masked]] 
Envoyé : mercredi 16 novembre 2005 22:38
À : GARCIN Sebastien RD-CORE-ISS; Francois Audet; Cullen Jennings
Cc : [email-masked]
Objet : RE: [Sipping-tispan] RE: Voicemail-uri draft

Sebastien,

Sorry I got behind on my email this week. Just to clarify slightly what Francois, Cullen and Dean have already said:

Comparison of the service-retargeting draft and the voicemail-uri draft revealed that they were both doing very similar things, and in fact were both based on RFC 3087. The main differences were:

1) Descriptive differences - service-retargeting was described as having somewhat broader scope than just voicemail, although technically it was very similar.

[SG: Yes what we need is broader than voicemail. So the question is why stick with "voicemail"?]

2) Namespace for retargeting reason. Although the service-retargeting draft proposed a new namespace for reasons, in fact existing SIP response codes (with extension if really necessary) can provide the required repertoire.
Dean has already explained the principles adopted at IETF 64 concerning reason namespaces.

[SG: I followed the "SIP Reason" namespaces debate. I can live with any other header or field if IETF think that the "Reason" is not fit for this purpose. Nonetheless using "SIP status codes" has no logical ground. Of course I can live with it, but I want to understand the rational.] 

The intention is to work on the voicemail-uri draft to make its description more general purpose and to ensure that the defined use of SIP response codes is sufficient to cover the different Q.732.2 diversion reasons.

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

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

John

> -----Original Message-----
> From: GARCIN Sebastien RD-CORE-ISS
> [mailto:[email-masked]]
> Sent: 15 November 2005 10:00
> To: Francois Audet; Cullen Jennings
> Cc: [email-masked]
> Subject: [Sipping-tispan] RE: Voicemail-uri draft
> 
> 
> François,
> 
> See below [SG]
> 
> sebastien
>  
> 
> -----Message d'origine-----
> De : Francois Audet [mailto:[email-masked]] Envoyé : mardi 15 
> novembre 2005 01:24 À : Cullen Jennings; GARCIN Sebastien RD-CORE-ISS 
> Cc : [email-masked]; Roland Jesske; Denis Alexeitsev; 
> CHATRAS Bruno RD-CORE-ISS; [email-masked]; 
> [email-masked]; Hans Erik van Elburg (RY/ETM); 
> [email-masked]; John Elwell Objet : RE: Voicemail-uri draft
> 
> > > From a technical point of view this draft is currently does
> > not meet
> > > Call Diversion requirements (and not only because of PSTN 
> > > interoperability).
> > > 
> > OK, you will need to help me understand what is needed and
> I do plan
> > to make some small changes to the draft.
> 
> >From a technical point of view, voicemail-uri is identical
> to service-retargeting. 
> 
> In fact, retargeting reason was a re-write of voicemail-uri.
> 
> [SG: Do you mean that retargeting only provides editorial changes 
> compared to voicemail-uri ? I don't agree.]
> 
> > > 1/ The draft does not address redirecting number which is
> mandatory
> > > requirement for TISPAN (if IETF won't consider billing,
> > TISPAN will be
> > > forced to define a P-header for this purpose)
> > IETF would probably call it accounting not billing but I
> don't think
> > IETF has any fundamental objections to billing.
> > Can you help explain the requirements here?
> 
> Cullen, I think section 8 is a little confusing with regards to 
> retargeting and probably needs some changes.
> 
> The target is intended to be mapped to the redirecting number, and we 
> should probably be silent on billing.
> 
> I assume other groups (like TISPAN) can discuss it if they want in 
> their own spec.
> 
> It does not need another header.
> 
> [SG: I don't mind if the draft is silent on billing. There are two 
> identities/parameters that need to be considered. The Original Called 
> party and the Redirecting party. Both need to be addressed by the 
> draft and have service justification (the first is used e.g. by 
> voicemails, the second for accounting).]
> 
> 
> > > 
> > > 2/ The draft assumes the SIP responses code are fit for
> > providing Call
> > > Diversion reason. We believe that this is not true and
> > seems more like
> > > a trick than a proper standard solution. I would recommend to use 
> > > explicite reason values based on ITU-T Q.733 as done in a
> number of
> > > other drafts.
> > 
> > Can you provide specific reasons why the SIP codes, or
> extensions to
> > them will not work. Many people at the IETF meetings provided many 
> > reason why a separate code space would not interoperate
> very well with
> > sip systems.
> 
> Agreed: some justification would be useful.
> 
> [SG: Again why use Reason codes when this is a service issue where 
> there can be no SIP codes involved? Seems very strange and has itself 
> no justification.]
> 
> > > 
> > > 3/ The draft assumes that there is "no call leg between B
> > and C". If
> > > this is the case, then this draft is not fit for Call Diversion 
> > > simulation service because this is how Call Diversion
> works whether
> > > IETF like it or not.
> > I'm a bit lost here. If there is a call leg like you
> describe then it
> > seems there would also be an B2BUA? seems it would be easy in this 
> > case but I imagine I am confused.
> > 
> > > 
> > > 4/ Privacy of the forwarding leg is not addressed.
> > OK - What is needed to be kept private and from whom?
> 
> My take is that Privacy should be in a privacy document, applicable 
> not just to voicemail, but to everything.
> 
> 
> > > 
> > > 5/ The scope of the draft should be made broader the
> > "voicemail", the
> > > voicemail application is one example application that
> > benefits from a
> > > Cal Diversion service
> > 
> > I agree. Can you tell me about the other services it is
> used for? I've
> > tried to make it clear the draft was applicable to many
> PSTN interop
> > situations.
> 
> IVR systems, contact centers, etc.
> 
> > > 
> > > Will the new version of the voicemail-draft will address
> all these
> > > issues in time for our needs ?
> > 
> > 
> > IETF is very consensus oriented and it is frustrating at
> times. There
> > has been several years of work to get this draft where it
> is - if it
> > can be tweaked a little and meet most of your needs, the
> questions you
> > need to ask yourself is there something else that is better
> than can
> > be done sooner? If you think that an alternative draft can reach 
> > consensus much sooner, I have no reasons to try and push
> this one. I'm
> > just trying to help on it.
> 
> Let us look at the draft and make sure it addresses your requirements.
> 
> _______________________________________________
> Sipping-tispan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Nov 2005 09:01:58 -0500

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

> [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 forw…

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