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

<> Wed, 20 October 2010 22:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E300C3A6900 for <>; Wed, 20 Oct 2010 15:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.277
X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ntRtqLmBwVKG for <>; Wed, 20 Oct 2010 15:36:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7B8143A6927 for <>; Wed, 20 Oct 2010 15:35:20 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id B2A90760002; Thu, 21 Oct 2010 00:40:40 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id A9640760001; Thu, 21 Oct 2010 00:40:40 +0200 (CEST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 00:36:48 +0200
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: Thu, 21 Oct 2010 00:36:43 +0200
Message-ID: <B11765B89737A7498AF63EA84EC9F5770A7793@ftrdmel1>
In-Reply-To: <>
Thread-Topic: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00
Thread-Index: Actu+FBLDrUpi9blRoCLCk/IVseS5AAENRc9AGQS29A=
References: <> <>
X-OriginalArrivalTime: 20 Oct 2010 22:36:48.0430 (UTC) FILETIME=[48419CE0:01CB70A7]
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: Wed, 20 Oct 2010 22:36:30 -0000

Hi Dale,

Thanks for your positive review.

See my answer in your mail [MM] 

Best Regards,

> -----Message d'origine-----
> De : 
> [] De la part de Worley, Dale R (Dale)
> Envoyé : lundi 18 octobre 2010 23:12
> À :
> Objet : Re: [sipcore] Comments on 
> draft-mohali-sipcore-reason-call-forwarding-00
> Here are some more comments on this draft:
> The term "call diversion" sounds more inclusive to the naive 
> ear than "call forwarding".  If the two terms are used 
> identically in the draft, it seems better to use only the 
> former, especially because the abbreviation "CDIV" is being used.
[MM] I agree with your statement, with call diversion no ambiguity is possible. I thought that "call forwarding" was the original term and I didn't wanted to change the habits but searching a simple acronym for the protocol value, 'CDIV' sounds good to me. 

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

> 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...
> In the example, it appears that the 302 response F3 is 
> informing the proxy that the call should be sent to 
> Voicemail.  In that case, the
> 302 would also carry the Reason header explaing why the 
> diversion is being done, which the proxy would subsequently 
> transcribe into the History-Info header of the new INVITE F5:
>     F3: 302 Bob ->
>     SIP/2.0 302 Moved Temporarily
>     Via: SIP/2.0/TCP;branch=z9hG4bK-ik80k7g-1
>     Via: SIP/2.0/TCP;branch=z9hG4bK-klj79f
>     From: Alice <;user=phone>; tag=1234567
>     To:;user=phone;tag=765432
>     Call-ID: c3x842276298220188511
>     Contact: <>
>     Reason: CDIV;cause=6;text="Deflection immediate response"
>     CSeq: 1 INVITE
>     Content-Length: 0

[MM] Right, I will add it in the next version. 
> In the example, F5 has two "Reason" headers attached to the 
> URI at index 1.  If you have more than one "header" attached 
> to a URI, only the first is introduced with "?", the 
> remainder are introduced with
> "&":
>     History-Info: <;user=phone?Reason=SIP
>               %3Bcause=302%3Btext="Moved Temporarily"&Reason=CDIV
>               %3Bcause=6%3Btext="Deflection immediate 
> response">;index=1,
>               <>;index=1.1;mp=1
[MM]Exact, I noted this mistake just after I submitted the draft :-/ Thanks.
> There are also some difficulties regarding the History-Info 
> headers in the examle; they don't appear to be consistently 
> applied to all the INVITEs.
[MM] ok, I will review it in detail.
> Dale
> _______________________________________________
> sipcore mailing list