Subject: [dispatch] New Version Notification fordraft-mohali-dispatch-reason-for-applications-00

From: <[email-masked]>
Date: Thu, 19 May 2011 19:01:33 +0200

Hello,

Here is a new version of the draft previously discussed in SIPCORE WG and quickly presented at the last DISPATCH meeting by Mary.
http://www.ietf.org/id/draft-mohali-dispatch-reason-for-applications-00.txt 

The draft proposes to extend the Reason header, allowing proxies to indicate an application-specific reason in the SIP message.

We think that it would be usefull to have this kind of application-specific reasons especially in the History-Info header when a call has been retargeted by an Application.

We would like to get some feedback on the proposed I-D and a confirmation of interest from the IETF community (DISPATCH).

Best Regards,

Marianne Mohali

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : jeudi 19 mai 2011 18:43
À : MOHALI Marianne RD-CORE-ISS
Cc : CHATRAS Bruno RD-CORE-ISS; MOHALI Marianne RD-CORE-ISS
Objet : New Version Notification fordraft-mohali-dispatch-reason-for-applications-00.txt

A new version of I-D, draft-mohali-dispatch-reason-for-applications-00.txt has been successfully submitted by Marianne Mohali and posted to the IETF repository.

Filename:	 draft-mohali-dispatch-reason-for-applications
Revision:	 00
Title:		 Extending the Session Initiation Protocol (SIP) Reason Header for Applications
Creation date:	 2011-05-19
WG ID:		 Individual Submission
Number of pages: 11

Abstract:
   This document defines a new protocol value &quot;Application&quot; for the
   Reason Header field and a new IANA Registry for registering
   application types.  This new value enables signaling that a request
   or response has been issued as a result of a decision made by a
   particular type of application or that an initial request has been
   retargeted as a result of an application decision.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 May 2011 19:34:11 -0400

marianne,

I continue to be troubled by this draft. I'll try to explain:

IIUC, these reasons are important to resolving "feature interaction" 
problems in systems you are involved with. Hence, I presume its 
important that the reasons be used "properly".

But I have very little idea what most of these applications are, so I 
don't see how I figure out to use them properly.

For instance, suppose I've implemented a sip "pbx" system that connects 
to the orange network via Martini. If I decide (somehow) that one of 
these codes applies to something I'm doing, is is ok for me to return 
the cause code? (E.g. I can certainly see my pbx implementing Voice 
Activated Dialing.)

I'm guessing the answer will be that this is all filtered out at the 
boundary to your network - that you would not honor any such reason code 
coming from in over the martini connection. (Did I guess right?) Or 
perhaps you would permit it for certain systems that are certified as 
complying to your requirements, or maybe that are operated by you.

What I'm getting at is that the definitions of these "applications" in 
this document is probably not a complete definition - that in reality it 
will be some 3GPP/IMS definition that matters.

If that is so, then this document *at least* needs a scope of 
applicability statement that it is intended only for IMS networks (or 
whatever the scope is.)

Perhaps I'm wrong. Perhaps its ok for any UA/proxy to decide when its 
appropriate to signal one of these based on the meager definitions in 
this document. If so, please tell me.

As a minor note, regarding the example in 3.1: I fail to understand what 
added value the application reason code provides over the sip 402 reason 
code. The sip code seems *more* precise. Is it that you put more 
credence in the 402 code if you believe it came from the "prepaid" 
application that you otherwise would?

	Thanks,
	Paul

On 5/19/2011 1:01 PM, [email-masked] wrote:
>     This document defines a new protocol value&quot;Application&quot; for the
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>