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

[<[e-mail]>]

Hi Dale,

Thanks for your positive review.

See my answer in your mail [MM] 

Best Regards,
Marianne

> -----Message d'origine-----
> De : [e-mail] 
> [mailto:[e-mail]] De la part de Worley, Dale R (Dale)
> Envoyé : lundi 18 octobre 2010 23:12
> À : [e-mail]
> 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:[e-mail];user=phone>; tag=1234567
>     To: sip:[e-mail];user=phone;tag=765432
>     Call-ID: c3x842276298220188511
>     Contact: <sip:[e-mail]>
>     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:[e-mail];user=phone?Reason=SIP
>               %3Bcause=302%3Btext="Moved Temporarily"&Reason=CDIV
>               %3Bcause=6%3Btext="Deflection immediate 
> response">;index=1,
>               <sip:[e-mail]>;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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>