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

[Paul Kyzivat <[e-mail]>]

Marianne,

Will you be attending the Beijing meeting?
Given the email activity on this, I think it could use a bit of 
discussion there.

	Thanks,
	Paul

On 10/22/2010 11:44 AM, [e-mail] wrote:
> Ok, maybe I should show a *normal* case where the Reason header is included in the UA response and then copied in the H-I. And also a situation where thoses values can be used directly in request (I don't know how).
> However, the voicemail case you mention is possible only for the last retargeting reason (the call could have been diverted several times). It could be usefull to store the previous reasons in the H-I for the case where a unified voicemail wants to join the firt diverting user box.
> You said also that it wouldn't need to consult the H-I but I think it would be necessary to know the diverting user identity to find he's mailbox (in H-I).
>
> Indeed, a dedicated H-I parameter could match the need but I already done this proposal unsucessfully and this solution would be quite different from the present.
>
> Marianne
>
>> -----Message d'origine-----
>> De : Paul Kyzivat [mailto:[e-mail]]
>> Envoyé : vendredi 22 octobre 2010 01:46
>> À : MOHALI Marianne RD-CORE-ISS
>> Cc : [e-mail]
>> Objet : Re: [sipcore] Commentson
>> draft-mohali-sipcore-reason-call-forwarding-00
>>
>> [as individual]
>>
>> I think maybe you misunderstood me.
>>
>> IMO its already somewhat of an abuse to include a header in
>> URI in the H-I header, in the URI that was captured for
>> inclusion in the H-I. If a UA received a URI in a 3xx
>> response, and it contained a Reason header, then it would
>> make perfect sense to put that into the H-I. But taking an
>> R-URI and grafting on a Reason header before putting it into
>> H-I seems at best a hack. But maybe that is water over the dam.
>>
>> The hack is compounded if the reason in the Reason header is
>> never intended to be used in a Reason header in a request
>> that is sent - rather that it is only intended to be used in
>> H-I in an already abusive way.
>>
>> BUT, I expect in fact that these reason values *could*
>> actually be useful in requests. If so, you would do yourself
>> a favor to point that out in the draft. In your example 4, as
>> Dale already pointed out, the Reason header doesn't appear in
>> INVITE F5. But it *could*, and it would make sense that it
>> should. That tells the voicemail system *directly* the reason
>> why it was contacted. It wouldn't necessarily need to consult
>> the H-I in an attempt to figure that out.
>>
>> If that is *not* useful - if such values should be ignored in
>> favor of analyzing the H-I entries - then I assert that
>> Reason should not be used for this. Rather H-I should use its
>> own header parameters to convey this sort of information.
>>
>> 	Thanks,
>> 	Paul
>>
>>
>> On 10/21/2010 5:05 PM, [e-mail] wrote:
>>> 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
>>>>
>>>
>>
>