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

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

	Thanks,
	Paul

On 10/20/2010 6:36 PM, marianne.mohali@orange-ftgroup.com wrote:
> Hi Dale,
>
> Thanks for your positive review.
>
> See my answer in your mail [MM]
>
> Best Regards,
> Marianne
>
>> -----Message d'origine-----
>> De : sipcore-bounces@ietf.org
>> [mailto:sipcore-bounces@ietf.org] De la part de Worley, Dale R (Dale)
>> Envoyé : lundi 18 octobre 2010 23:12
>> À : sipcore@ietf.org
>> 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 ->  proxy.example.com
>>
>>      SIP/2.0 302 Moved Temporarily
>>      Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
>>      Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK-klj79f
>>      From: Alice<sip:+15551001@example.com;user=phone>; tag=1234567
>>      To: sip:+15551002@example.com;user=phone;tag=765432
>>      Call-ID: c3x842276298220188511
>>      Contact:<sip:voicemail@example.com>
>>      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:<sip:+15551002@example.com;user=phone?Reason=SIP
>>                %3Bcause=302%3Btext="Moved Temporarily"&Reason=CDIV
>>                %3Bcause=6%3Btext="Deflection immediate
>> response">;index=1,
>>                <sip:voicemail@example.com>;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@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>