Re: [sipcore] Reason as a parameter rather than an escaped header

I'm not especially particular about which of the various patterns of H-I 
entries are permitted - could be one or more of them, with discretion 
about what to include. (Though there could be merit in permitting 
omission of extra "virtual" entries that add no value.)

But whatever it is, the draft should say *something* that is sufficient 
to determine if the usage chosen is valid or not.

	Thanks,
	Paul

On 11/25/2010 5:48 PM, marianne.mohali@orange-ftgroup.com wrote:
>
>   Hi,
>
> My adding [MM]
>
> Marianne
>
>> -----Message d'origine-----
>> De : sipcore-bounces@ietf.org
>> [mailto:sipcore-bounces@ietf.org] De la part de Hadriel Kaplan
>> Envoyé : jeudi 25 novembre 2010 12:57
>> À : Paul Kyzivat
>> Cc : Worley, Dale R (Dale); sipcore@ietf.org
>> Objet : Re: [sipcore] Reason as a parameter rather than an
>> escaped header
>>
>>
>> On Nov 23, 2010, at 7:06 PM, Paul Kyzivat wrote:
>>
>>> But my remaining concern is about the rules in 4244bis
>> regarding how
>>> and when Reason headers are included in the H-I entries. It still
>>> seems to me that the text only talks about including them due to a
>>> response having been received. Where is the language that discusses
>>> adding a reason when retargeting is performed for some reason
>>> unrelated to a response?
>>>
>>> While I think one can argue that a server doing such
>> retargeting can
>>> imagine having sent the request to a virtual redirect
>> server and then
>>> processing the response from it, ISTM that would then call
>> for adding
>>> H-I entries for those steps.
>>
>> Right, that's the main piece to figure out first.  We already
>> agreed that 4244bis tells proxies to create H-I entries for
>> internal retargeting decisions.  What's not clear is what
>> internal H-I entries have to be created, and whether the
>> embedded Reason header value of the *SIP* type can be used
>> for such cases.
>>
>> For example, suppose Alice called Bob, and proxy-1 internally
>> diverts it to Charlie because it knows Bob is busy, *without*
>> having to send the INVITE to Bob and getting a 486 response.
>>
>> Is it legit for the H-I look like this:
>> History-Info:<sip:bob@example.com?Reason=SIP%3Bcause%3D486>;index=1
>> History-Info:<sip:charlie@example.com>;index=1.1;mp=1
>> History-Info:<sip:charlie@192.1.2.3>;index=1.1.1;rc=1.1
>>
>> Or does it have to look like this:
>> History-Info:<sip:bob@example.com>;index=1
>> History-Info:<sip:bob@127.0.0.1?Reason=SIP%3Bcause%3D486>;index=1.1
>> History-Info:<sip:charlie@example.com>;index=1.2;mp=1
>> History-Info:<sip:charlie@192.1.2.3>;index=1.2.1;rc=1.2
>>
>> Or does it have to do something like this:
>> History-Info:
>> <sip:bob@example.com?Reason=Internal%3Bcause%3D486>;index=1
>> History-Info:<sip:charlie@example.com>;index=1.1;mp=1
>> History-Info:<sip:charlie@192.1.2.3>;index=1.1.1;rc=1.1
>>
> [MM] Or (as per 3GPP CDIV 24.604 for call forwarding busy)
> History-Info:<sip:bob@example.com>;index=1
> History-Info:<sip:charlie@example.com;cause=486>;index=1.1;mp=1
> History-Info:<sip:charlie@192.1.2.3>;index=1.1.1;rc=1.1
>
>> -hadriel
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>