Subject: Re: [dispatch] charter proposal for draft-mohali-dispatch-reason-for-applications

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jun 2011 11:37:18 +0200

Hi,

Eventhough I have some minor issues with the proposed solution, I DO think there is a need to solve the problem indicated in the proposed Problem Statement, and I support to start working on this.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 24. toukokuuta 2011 20:23
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [dispatch] charter proposal for 
> draft-mohali-dispatch-reason-for-applications
> 
> Hi,
> 
> I am not proposing a new working group but trying to find the 
> good place to solve the following problem.
> 
> Problem Statment
> ----------------
> 
> Decisions made by one application about how to handle a 
> session often depend on which other types of applications are 
> involved in this session. Hence, in the context of SIP, when 
> several remote applications are involved in the processing of 
> one session, there is a need for a mechanism enabling one 
> application to explicitly identify itself when issuing or 
> re-targeting a request or response. This will enable 
> applications receiving this information to take appropriate 
> decisions on how to further process the session.
> 
>    1.  Need to convey the identity of the application having 
> "acted" on the call, in order to allow a downstream 
> application to avoid undesirable service interactions (e.g. 
> by deciding whether to execute a particular feature depending 
> on the call history).
>    2.  Need to convey the identity of the application having 
> caused a specific number translation and allow the transfer 
> target to easily find out the original number that this 
> application had received, even in case multiple successive 
> number translations occured.
>    3.  Need to convey the identity of the application having 
> released the call towards an upstream application that can 
> take specific decisions.
> 
> The draft is available at
> http://tools.ietf.org/html/draft-mohali-dispatch-reason-for-ap
plications
> -00
> 
> 
> Charter proposal
> ----------------
> The Reason header field [RFC3326] provides a mechanism to 
> signal the reason why a SIP request or response was issued or 
> why an initial request was retargeted.
> I-D draft-mohali-dispatch-reason-for-applications proposes to extend
> RFC3326 registering a new protocol value "Application" for 
> the Reason Header field and a for registering application 
> types (cause values). The extension process is similar to 
> RFC4411 that also extend the Reason header.
> This protocol value can be used anywhere the presence of a 
> Reason Header field is allowed.
> For each new registered value, it has to be defined the following:
> - Cause value:  this is an identifier number corresponding to 
> the cause value of the protocol-cause parameter in the Reason 
> header field.
> - Reason text:  this is a unique string identifying the 
> application name. The reason text is intended to give a short 
> textual description of the application.
> - Description:  this is a description of the application and 
> the conditions under which this reason-value is used. 
>  
> The work consist in extending RFC3326 (Reason header) for 
> applications needs.
> 
> 
> Goals and Milestones
> --------------------
> 
> July 2011 Update to draft-mohali-dispatch-reason-for-applications
> addressing concerns raised in the mailing list
> 
> July 2011 Present update to
> draft-mohali-dispatch-reason-for-applications at IETF 81
> 
> Nov 2011 Present update to 
> draft-mohali-dispatch-reason-for-applications
> at IETF 82
> 
> Mar 2012 Submit draft-mohali-dispatch-reason-for-applications 
> to IESG as Proposed Standard RFC
>  
> 
> Best Regards,
> Marianne
>  
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: <[email-masked]>
Date: Tue, 7 Jun 2011 11:49:48 +0200

+1

Mit freundlichen Grüßen
Roland Jesske

Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 58 12766 (Tel.)
+49 391 580 133 831 (Fax)
+49 171 8618-445  (Mobil)
E-Mail: mailto:[email-masked]
http://www.telekom.de

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft Bonn
USt-IdNr. DE 814645262

Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Christer Holmberg
> Gesendet: Dienstag, 7. Juni 2011 11:37
> An: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Betreff: Re: [dispatch] charter proposal for
> Eventhough I have some minor issues with the proposed
> solution, I DO think there is a need to solve the problem
> indicated in the proposed Problem Statement, and I support to
> start working on this.
>
> Regards,
>
> Christer
>
>