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

Paul Kyzivat <> Wed, 20 October 2010 23:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDEA83A657C for <>; Wed, 20 Oct 2010 16:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.197
X-Spam-Status: No, score=-110.197 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DGF47qN1eogH for <>; Wed, 20 Oct 2010 16:08:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8ED0C3A67FA for <>; Wed, 20 Oct 2010 16:08:24 -0700 (PDT)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAOMTv0xAZnwN/2dsb2JhbAChUHGjI5xIAoVIBIpLgwQ
X-IronPort-AV: E=Sophos;i="4.57,357,1283731200"; d="scan'208";a="172934298"
Received: from ([]) by with ESMTP; 20 Oct 2010 23:09:58 +0000
Received: from [] ( []) by (8.13.8/8.14.3) with ESMTP id o9KN9wpm021656 for <>; Wed, 20 Oct 2010 23:09:58 GMT
Message-ID: <>
Date: Wed, 20 Oct 2010 19:09:58 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
References: <> <> <B11765B89737A7498AF63EA84EC9F5770A7793@ftrdmel1>
In-Reply-To: <B11765B89737A7498AF63EA84EC9F5770A7793@ftrdmel1>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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 23:08:26 -0000

[as participant]

I think I'm replying to an earlier message, not this one, but the point 
is the same:

IIUC the intent of this work is to define new values for the Reason 
header, that can be used in a Reason header inserted into a URI in 
History-Info. And there is *no* expectation that these values would be 
used in a Reason header in a message that is actually sent. Is that right?

If so, it at least sounds like an abuse - that some other mechanism 
should be used.

OTOH, if there is some plausible reason to use this in an actual request 
then I find it much less troubling.


On 10/20/2010 6:36 PM, wrote:
> Hi Dale,
> Thanks for your positive review.
> See my answer in your mail [MM]
> Best Regards,
> Marianne
>> -----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
> _______________________________________________
> sipcore mailing list