Re: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00

"Worley, Dale R (Dale)" <> Thu, 21 October 2010 19:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9434F3A681F for <>; Thu, 21 Oct 2010 12:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.154
X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X1io5tv6T5EI for <>; Thu, 21 Oct 2010 12:47:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B04543A6802 for <>; Thu, 21 Oct 2010 12:47:15 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,219,1286164800"; d="scan'208";a="213076733"
Received: from unknown (HELO ([]) by with ESMTP; 21 Oct 2010 15:48:50 -0400
X-IronPort-AV: E=Sophos;i="4.58,219,1286164800"; d="scan'208";a="528841682"
Received: from unknown (HELO ([]) by with ESMTP; 21 Oct 2010 15:48:50 -0400
Received: from ([]) by ([]) with mapi; Thu, 21 Oct 2010 15:48:49 -0400
From: "Worley, Dale R (Dale)" <>
To: "" <>, "" <>
Date: Thu, 21 Oct 2010 15:47:26 -0400
Thread-Topic: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00
Thread-Index: Actu+FBLDrUpi9blRoCLCk/IVseS5AAENRc9AGQS29AAL9Zyig==
Message-ID: <>
References: <> <>, <B11765B89737A7498AF63EA84EC9F5770A7793@ftrdmel1>
In-Reply-To: <B11765B89737A7498AF63EA84EC9F5770A7793@ftrdmel1>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00
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: Thu, 21 Oct 2010 19:47:17 -0000

>> From: Dale Worley

> From: Marianne Mohali

> > Section 3 does not give any BNF for CDIV, though it quotes
> > all of the established BNF for the Reason header. Clearly,
> > what is intended (but not stated) is:
> >
> >     protocol  =/  "CDIV"
> [MM] What is just after the established BNF is not good? I've used
> RFC4411 as a model.

It is good to describe the change in words, but it is better to
describe the change in both words and in BNF -- some people find one
method easier to understand than the other method.  And since the two
methods are vulnerable to different kinds of errors, using both makes
it easier to discover errors in the definition.

As far as I can tell, RFC 4411 contains no BNF at all, so it is not a
good model of how to update BNF.

> > In regard to listing the CDIV cause values, it seems to me
> > that there should be an existing encoding of call diversion
> > reasons somewhere within the 3GPP specification, and it would
> > be more effective for the draft to reference that table
> > (which would be maintained by 3GPP) rather than defining a
> > new IANA registry (which would be used almost exclusively by 3GPP).
> [MM] Right, but the existing CDIV cause values (described in 3GPP)
> are a corruption of SIP response codes and brings confusion. It is
> the initial reason of this draft. Your idea of mixing both sound
> good to me: register a new protocol value "CDIV" but keep the
> reasons values as in 3GPP. The problem I see is that reason values
> are described in RFC4458 not for the Reason header but for an URI
> parameter and I'me not sure it is possible to re-use it. An other
> way could be to registering cause values but with the same values
> as today instead of (1 to 8). Let's think about it...

The ideal situation would be if 3GPP had a clear taxonomy of diversion
situations, and the CDIV cause values were an encoding of those
categories.  In particular, we expect CDIV to be generated by a 3GPP
system, and so 3GPP would clearly specify the diversion situations
which are described by the cause values.

It is not ideal if Sipcore defines these cause values, because
our understanding of call diversion services probably differs from
the understanding of 3GPP.