Subject: [Sipping-tispan] Voicemail-uri draft

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Mon, 14 Nov 2005 11:55:01 +0100

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

>From a technical point of view this draft is currently does not meet Call Diversion requirements (and not only because of PSTN interoperability).

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)

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.

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. 

4/ Privacy of the forwarding leg is not addressed.

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

Will the new version of the voicemail-draft will address all these issues in time for our needs ? 

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: Dean Willis <[email-masked]>
Date: Tue, 15 Nov 2005 10:45:54 -0600

On Nov 14, 2005, at 4:55 AM, GARCIN Sebastien RD-CORE-ISS 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)
>
>
Just for background consideration:

Under the procedures of RFC 3427, registration of a P-header requires  
at least an informational track RFC.  So any P-header defined only in  
TISPAN will not be entered in the IANA registry of P-headers.  
Furthermore, the RFC 3427 procedures (enforced by the IESG) do not  
allow the publication of an informational draft that is in conflict  
with or overlaps ongoing work in the IETF.

That being said, the general redirection target draft resulting from  
a combination of the two previous drafts is expected to meet your  
needs, at least to the level understood during the IETF meeting. And  
it will be much faster to progress at IETF than new work would.

> 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.
There is currently a rough consensus in the SIP working group NOT to  
define new reason codes from foreign namespaces and allow their use  
in responses. This was discussed extensively at last weeks meeting,  
and has been the subject of much discussion on the SIP email list.  
The agreed general methodology is, where needed, to define  new SIP  
response codes (like 433 Anonymity Disallowed, as specified in draft- 
rosenberg-sipping-acr-code-00.txt) that provide a semantic mapping  
between foreign-namespace "reasons" and SIP in an automata- 
processable way. Not everybody likes this approach, but it is the  
consensus position.

Cases where a proxy with causal knowledge makes a forwarding decision  
and wishes to express that causal knowledge in the resulting request  
are better dealt with using request parameters in the style described  
by RFC 3087. The informational draft we're talking about here shows  
one way of applying the RFC 3087 methodology to the given problem.

> 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.
>
> 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 believe the new draft is expected to address your requirements,  
although we'll need to work together to make sure it does. Of course,  
we can't assure delivery on any specific date, but we're intending to  
move the draft forward in a timely and workmanlike manner. But it's  
not done until the authors, the working group, the IESG, the IETF at  
large, and the RFC Editor say it is done.

--
Dean Willis
co-chair,

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 14 Nov 2005 15:41:51 -0800

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:

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

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

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

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

> Will the new version of the voicemail-draft will address all these issues in

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.