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

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Tue, 15 Nov 2005 10:17:27 +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.

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

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

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

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

> 
> 4/ Privacy of the forwarding leg is not addressed.
OK - What is needed to be kept private and from whom?

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

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

[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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Nov 2005 09:13:47 -0500

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

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: David R Oran <[email-masked]>
Date: Tue, 15 Nov 2005 11:23:25 -0500

On Nov 15, 2005, at 9:13 AM, Paul Kyzivat wrote:

>>> 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?
>> [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
> 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?
>
Dividends to the redirecting service provider's shareholders.