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

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Tue, 15 Nov 2005 11:00:09 +0100

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

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Tue, 15 Nov 2005 17:24:55 +0100

Paul,

If you are talking about call forwarding between entity in the same entreprise then there of course charging of B for the B-C leg may not be relevant, but that's doesn't mean that in all cases the redirecting party information is not required.

The word "leg" has no formal definition (and has no relation to a given protocol) but this is the terminology used for the Call Forwarding service. It just simplifies life...

Regards
sebastien

-----Message d'origine-----
De : Paul Kyzivat [mailto:[email-masked]] 
Envoyé : mardi 15 novembre 2005 17:19
À : Hans Erik van Elburg (RY/ETM)
Cc : GARCIN Sebastien RD-CORE-ISS; Cullen Jennings; [email-masked]; [email-masked]; Denis Alexeitsev
Objet : Re: [Sipping-tispan] RE: Voicemail-uri draft

Hans Erik van Elburg (RY/ETM) wrote:
> Hi Paul,
> 
> I thought we are discussing call forwarding, why are you throwing in 
> call transfer now?

Oh, sorry. I just screwed up while writing it.

> It is interesting, but I think confuses the discussion.
> 
> You can ask the same question for call forwarding of course.

Right. Assume I meant that X calls Y who forwards to Z. X and Z are in the same enterprise, and Y is far away.

> And this
> comes basically down to a requirement from operators where they offer 
> a service/capability/"value add" to a user that they would like to 
> charge for.

I'm just wondering exactly what it is they will charge for. Are they actually going to insist on staying in the loop in order to preserve the fiction that there are separate call legs to charge for? Or are they going to get out of the loop but still charge as if they were in? Or is Y going to pay half of the (nonexistent) charge for the call between X and Z? Or ???

The basic issue is that phrasing this in terms of "call legs" makes no sense.

	Paul

> Best Regards,
> 
> /Hans Erik
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Tuesday, November 15, 2005 3:14 PM
> To: GARCIN Sebastien RD-CORE-ISS
> Cc: Cullen Jennings; [email-masked]; 
> [email-masked]; Denis Alexeitsev
> Subject: Re: [Sipping-tispan] RE: Voicemail-uri draft
> 
> 
> 
> GARCIN Sebastien RD-CORE-ISS wrote:
> 
> 
>>>requirement for TISPAN (if IETF won't consider billing, TISPAN will 
>>>be
> 
> 
> IETF has any fundamental objections to billing. Can you help explain 
> the requirements here?
> 
>>[SG: The redirecting party is the party that should get billed for the
> 
> 
>>leg it created. For this leg the redirecting party plays the same role
> 
> 
>>of the P-Asserted-ID with regards to billing. This is why it is 
>>required in SIP. Also if the call encountered several call forwarding 
>>events (e.g. I forward my call to my mobile phone, that then gets 
>>forwarded to my voicemail), the redirecting number will be different 
>>from the original called number (i.e. termed as the "target" in the 
>>voicemail draft).We therefore need both identities.]
> 
> 
> I keep trying to understand what this is going to mean in practice, 
> when there aren't really separate call legs. Consider the following:
> 
> - X calls Y
> - Y transfers X to Z
> - X and Z are using phones connected to a single enterprise sip system
> - Y is across the world on a public network
> 
> At the completion of the transfer there is only one "call leg", 
> between X and Z, on a private network. So what is it that Y is paying for?
> 
> 	Paul
>

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Wed, 16 Nov 2005 19:00:17 +0100

François,

1/ When you say that the "To" header does not change, you are assuming the call forwarding service performed according to SIP proxy rules. There is no such assumption in IMS and I don't think the draft should make such an assumption. 

With regards to the history-info, Call Forwarding service is one example of the general "retargeting" concept. When I dial a special service number that gets translated into a geographic number for proximity service, this can be done via "retargeting" and has nothing to do with Call Forwarding. 

History-info deals perfectly with this type of retargeting cases but unfortunatly does not have an embedded indicator characterizing such call forwarding service event. Mixing up history-info and "target" seems pretty messy.

In fact, this was one of the reason for wanting to add a "Reason header" to the history-info draft which I though was a good idea at the time (see draft-elwell-redirecting-reason).

sebastien

-----Message d'origine-----
De : Francois Audet [mailto:[email-masked]] 
Envoyé : mercredi 16 novembre 2005 18:40
À : GARCIN Sebastien RD-CORE-ISS; Cullen Jennings; [email-masked]
Objet : RE: Voicemail-uri draft

> Hi,
> 
> Further comments:
> 
> 1/ How to convey the original called identity
> ---------------------------------------------
> I was told that the "To" header was meant to convey the original 
> called identity while the target was to convey the redirecting 
> identity.
> 
> This prevents the Call Forwarding service to change the "To" 
> header (and set it to the logical "forwarded-To" identity). 
> In this respect the service-retargetting draft is better than the 
> voicemail-uri draft.

I don't understand why you are confused. 

It is exactly the same for voicemail-uri and for service retargeting.

In both cases (i.e., in SIP in general), you can not change the To field.

The target (in voicemail-uri) and old-target (in service retargeting) are exactly the same thing.

> Additionnaly, some signaling system such as H.323 (without H.450 
> series) are only capable of providing the redirecting identity. In 
> this case there is no Original Called identity and the mapping to and 
> from SIP will be impossible.
> 
> 2/ Redirecting counter
> ----------------------
> In certain situations, operators may wish to limit the number of call 
> forwardings (e.g. they don't want to risk loops
> A->B->A). There is a need to be able to count the number of
> call forwarding events (see levy-draft for example).  

This is recorded in History-Info.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 14 Nov 2005 18:24:21 -0600

> OK, you will need to help me understand what is needed and I 
> do plan to make some small changes to the draft.

> IETF would probably call it accounting not billing but I 
> don't think IETF has any fundamental objections to billing. 

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.

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

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

My take is that Privacy should be in a privacy document,
applicable not just to voicemail, but to everything. 

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

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

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Tue, 15 Nov 2005 10:10:32 +0100

Hi,

See below [SG]

Regards,
sebastien 

-----Message d'origine-----
De : Cullen Jennings [mailto:[email-masked]] 
Envoyé : mardi 15 novembre 2005 00:42
À : 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]; Francois Audet; John Elwell
Objet : Re: Voicemail-uri draft

Hi - I added John and Francois on this thread because they have helped explain some of this to me before.

On 11/14/05 2:55 AM, "GARCIN Sebastien RD-CORE-ISS"
<[email-masked]> wrote:

> Hi cullen,
> 
> It seems that in Vancouver, IETF people wanted to use the 
> voicemail-draft for the Call Diversion simulation service.
> 
> There are both technical and non-technical issues that need to be 
> raised at this point. From a non technical point of view TISPAN needs 
> to have a solution for Call Diversion in time for Release 1 (this 
> means we need something in time for the end of the month).
Right, this draft was in the RFC editor Q so many of us felt if had much better of chance of making the deadline than any other approach. For something this critical on such a short timeline, I hope that in the future you get to come to the meeting so we can get time to resolve theses issues in realtime. 

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

> requirement for TISPAN (if IETF won't consider billing, TISPAN will be 

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?

[SG: The redirecting party is the party that should get billed for the leg it created. For this leg the redirecting party plays the same role of the P-Asserted-ID with regards to billing. This is why it is required in SIP. Also if the call encountered several call forwarding events (e.g. I forward my call to my mobile phone, that then gets forwarded to my voicemail), the redirecting number will be different from the original called number (i.e. termed as the "target" in the voicemail draft).We therefore need both identities.]

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

[SG: I'm not saying it does not work, I am saying it is ugly and strange to indicate a SIP codes that sometimes does not exist (e.g. in case of Call Forwarding Unconditionnal). Current sip system implement the levy draft which already has an explicit call forwarding reason which what we need. SIP system that does not implement any Call Forwarding draft will not have to worry because they would ignore it.]

> 
> 3/ The draft assumes that there is "no call leg between B and C". If 
> 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.

[SG: The call leg is nothing to do with protocol but with service design. The service we have in mind is rendered in an AS which can plays either of proxy (this is preferable) or a B2BUA (when required for service purposes). The portion of the call created by the forwarding party is termed as a leg. This helps in designing service interactions and charging models.] 

[SG: The forwarding party may not whish to appear a being the author of the redirection. This needs to be addressed, this is also covered in the levy draft.]

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

[SG: Call forwarding from fixed to mobile phone,towards a secondary home..., call forwarding can be used if you want to automatically forward a call towards your new number when your number has changed...] 

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

[SG: There has been the levy draft which is ok and widely implemented but which IETF has chosen to ignore for very long time even though a number of people want a standardized solution for a long time now. The service-retargetting was a good progress, I was confused by the fact IETF seems to have choosen to move backwards and use the voicemail-uri draft. At least it is not clear what the decision was from the IETF minutes.]

 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.

[SG: OK, thanks]

> Thanks,
> Sébastien Garcin
> France Télécom R&D

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 16 Nov 2005 11:40:25 -0600

> I was told that the "To" header was meant to convey the 
> original called identity while the target was to convey the 
> redirecting identity. 
> 
> In this respect the service-retargetting draft is better than 
> the voicemail-uri draft.

In both cases (i.e., in SIP in general), you can not change the 
To field.

The target (in voicemail-uri) and old-target (in service retargeting)
are exactly the same thing.

> Additionnaly, some signaling system such as H.323 (without 
> H.450 series) are only capable of providing the redirecting 
> identity. In this case there is no Original Called identity 
> and the mapping to and from SIP will be impossible.
> 
> 2/ Redirecting counter
> ----------------------
> In certain situations, operators may wish to limit the number 
> of call forwardings (e.g. they don't want to risk loops

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 16 Nov 2005 21:37:39 +0000

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.

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.

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.

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.

John

> 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
>  
> 
> 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
> [SG: Do you mean that retargeting only provides editorial 
> changes compared to voicemail-uri ? I don't agree.]
> 
> don't think 
> 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. 
> 
> [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).]
> 
> 
> > > 
> extensions to 
> [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.]
> 
> > > 
> times. There

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Nov 2005 21:14:02 +0000

Sebastien,

In-line

John

> Sent: 17 November 2005 08:49
> To: Elwell, John; Francois Audet; Cullen Jennings
> Subject: RE: [Sipping-tispan] RE: Voicemail-uri draft
> 
> Hi John,
> 
> See below,
> 
> sebastien
> 
> 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"?]
[JRE] I thought this had already been explained. It is because there is
already agreement that this draft be progressed as an individual
informational RFC, so slight modifications to this draft, rather than a
brand new draft, will speed up the process.

> 
> 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.] 
[JRE] A new namespace would duplicate some of the existing SIP response code
namespace, e.g., busy, no reply. Also the reasons given by Paul.

> 
> 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.] 
[JRE] The point is, a history-info entry that contains a voicemail-uri can
be considered as service retargeting, whereas one without can be considered
as normal routing. This principle is identical to that in the
service-retargeting draft.

> > 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
> > 
> > [SG: Do you mean that retargeting only provides editorial changes 
> > compared to voicemail-uri ? I don't agree.]
> > 
> > [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).]
> > 
> > 
> > > > 
> > [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.]
> > 
> > > > 
> > My take is that Privacy should be in a privacy document, applicable 
> > not just to voicemail, but to everything.
> > 
> > 
> > > >

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Fri, 18 Nov 2005 09:45:50 +0100

Hi,

See in-line

seabastien

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

Sebastien,

In-line

John

> 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"?]
[JRE] I thought this had already been explained. It is because there is already agreement that this draft be progressed as an individual informational RFC, so slight modifications to this draft, rather than a brand new draft, will speed up the process.

[SG: I am aware of this. What I meant was that the title and the scope needs to reflect that we are not only dealing with voicemails (hopefully in the next version). Also there is a need to change the fact that the "To" conveys the redirecting party, add privacy to the redirecting leg...To me it's quite some modification.] 

> 
> 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.
> [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.]
[JRE] A new namespace would duplicate some of the existing SIP response code namespace, e.g., busy, no reply. Also the reasons given by Paul.

[SG: I followed the discussion. IMHO there is confusion between a SIP status code and a service reason.]

> 
> 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 
> 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.]
[JRE] The point is, a history-info entry that contains a voicemail-uri can be considered as service retargeting, whereas one without can be considered as normal routing. This principle is identical to that in the service-retargeting draft.

[SG: I see. This means that in order to check how many Call Forwarding event occured the SIP parser has go scann into every history-info entry to see if it contains a "target" parameter. Having a counter would make things more simple for applications but I guess it works. Also this will have to be very carefully explained in the draft because it become very bizarre to have embedded target in an history-info.]