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

[<[e-mail]>]

Hi Paul,

My answer in your text [MM]

Thanks,
Marianne
> -----Message d'origine-----
> De : [e-mail] 
> [mailto:[e-mail]] De la part de Paul Kyzivat
> Envoyé : jeudi 21 octobre 2010 01:10
> À : [e-mail]
> Objet : Re: [sipcore] Commentson 
> 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?
[MM] It is right for the draft in subject (reason for call diversion) but not for the other draft (if it is what you mean by "an earlier message") you seem to refer (Reason for applications) where new values could be added "everywhere".
> 
> 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.
[MM]  Answering only for the draft in subject; it's true that it has a narrow scope but, at the end, the new values could be present everywhere the History-Info header is. At this time, I described our need but I could think about a larger use of those new values (eg. directly in a SIP error response due to a UA retargeting).
> 
> 	Thanks,
> 	Paul
> 
> On 10/20/2010 6:36 PM, [e-mail] wrote:
> > 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
> >>
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>