Re: [Sipping-tispan] Voicemail-uri draft

[Dean Willis <[e-mail]>]

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

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