Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?

<> Fri, 19 November 2010 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 100453A6818 for <>; Fri, 19 Nov 2010 07:31:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.766
X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OT0A916msEei for <>; Fri, 19 Nov 2010 07:31:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 37C023A6812 for <>; Fri, 19 Nov 2010 07:31:35 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 2E73B8B8008; Fri, 19 Nov 2010 16:33:14 +0100 (CET)
Received: from (unknown []) by (Postfix) with ESMTP id 267258B8002; Fri, 19 Nov 2010 16:33:14 +0100 (CET)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Nov 2010 16:32:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 19 Nov 2010 16:32:19 +0100
Message-ID: <B11765B89737A7498AF63EA84EC9F5771EF0BF@ftrdmel1>
In-Reply-To: <>
Thread-Topic: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
Thread-Index: AcuCGi1fz/ZUOl2uSquWRR64hshQVgDkFe3A
References: <><> <>
From: <>
To: <>, <>
X-OriginalArrivalTime: 19 Nov 2010 15:32:21.0113 (UTC) FILETIME=[F4F1EE90:01CB87FE]
Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Nov 2010 15:31:38 -0000


The objective of draft-mohali-sipcore-reason-extension-application is to know why and, more exactly, which application has influenced the session.
4244bis do not cover the need but is necessary to meet the need.

3 Use-cases for application-specific Reason:
1. in accordance with RFC3326, in a BYE or CANCEL to explain why a session has been released/canceled (general use-case) 
2. in accordance with 4244bis, escaped in the History-Info header (2 sub-cases)
    2.1. When the call is retargeted (R-URI changed), explaining that it is because of an application-specific internal decision.
    2.2. When there is no retargeting (R-URI unchanged), just to mark in the session history that this application has been invocated.

Work on RFC4244bis has to be concluded and this draft has a different scope. I don't see any interaction issues.

Why not finish RFC4244bis and use this draft both to enrich Reason header in general and to meet the needs using History-Info (already covering the use of Reason)?

Hadriel, you said "When I read Marianne's draft, it sounds like the use-case she's trying to cover is call-forwarding" 
but the presented draft has really NO link with Call Forwarding (it is an other draft ;-).


> -----Message d'origine-----
> De : 
> [] De la part de Hadriel Kaplan
> Envoyé : vendredi 12 novembre 2010 04:32
> À : Adam Roach
> Cc : WG
> Objet : Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
> I'd like a clarification. 
> You said:
> > "limit bis
> > changes to [those necessary to] satisfy target uri requirements."
> If by that you mean literally just to enable GRUU delivery, 
> we've already exceeded that.  You don't need an "mp" tag for 
> that, for example, afaict.
> But I'm also not sure it's fair to be that restrictive in 
> your interpretation of what the bis can change.  Obviously we 
> have to constrain the scope, to actually get anywhere.
> But there's no point in publishing a document if it doesn't 
> solve a problem people actually have, just for the sake of 
> publishing a document. 
> [soapbox]
> An RFC is not an end goal in itself - it's a means to an end, 
> namely for enabling interoperable protocols people will 
> *actually use*.
> [/soapbox]
> (I know we all agree on this, I'm just venting)
> BTW, I'm not sure Marianne's use-case requires *ANY* 
> normative changes to rfc4244bis.  I was just commenting that 
> it would have been nice to really understand if rfc4244bis 
> did not cover it.  This is similar to Cullen's concern about 
> use-cases/application-examples.  We need to make sure the 
> changes we're making are actually useful. (I think they 
> *are*, or are as close as we can get, but that doesn't mean 
> we shouldn't go through the exercise... using H-I just isn't 
> that simple/obvious)
> -hadriel
> On Nov 11, 2010, at 9:53 PM, Adam Roach wrote:
> > [as chair]
> > 
> > On 11/12/10 10:06 AM, Hadriel Kaplan wrote:
> >> When I read Marianne's draft, it sounds like the use-case 
> she's trying to cover is call-forwarding, for things like 
> voicemail systems to be able to detect/process.  So what 
> really confuses me is I thought one of the basic applications 
> 4244bis was trying to enable was exactly that one.  Right?  
> If it's not sufficient to achieve that, I think we've screwed 
> up somewhere... or at least need to make sure it's not 
> something we can fix in 4244bis, because now would be a 
> really good time to fix it.  :)
> > 
> > At IETF 75, when we were discussing the applicability of 
> 4244bis to the 
> > SIPCORE charter (as opposed to simply developing a new 
> document that was 
> > limited to describing how to use 4244 to deliver URI 
> parameters), one of 
> > the rather important points that was made was that we would 
> "limit bis 
> > changes to [those necessary to] satisfy target uri requirements."
> > 
> > If the RAI community at large wants to expand this to 
> include a general 
> > tune-up and/or kitchen-sinking of 4244, then we need to 
> figure out a way 
> > to put the SIPCORE milestone to rest and then send the rest of the 
> > changes to DISPATCH. I have no interest in letting this 
> milestone drag 
> > on as people come up with new things they'd like to see 
> added or changed.
> > 
> > /a
> _______________________________________________
> sipcore mailing list