[sipcore] draft-mohali-sipcore-reason-extension-application-00

[Paul Kyzivat <[e-mail]>]

[as individual]

I took another look at this draft, and have a few observations/comments:

Its claimed that in cases where retargeting is due to a 3xx response, 
then the reason is 3xx, while in the cases of interest in this draft the 
reason is one of the new application reason codes.

But these are not mutually exclusive cases. All of the "application" 
cases called out could be implemented by sending the request to an 
application server that then returns a 3xx response with the value. If 
so, anything downstream that wishes to identify the reason would 
presumably want the application reason, which would perhaps have been 
lost in this process.

ISTM that to resolve that, the redirect server would affix the reason 
header with the application code to the contact in the 3xx. Then, the 
proxy that recurses on the 3xx would place contact with the embedded 
reason header into the H-I, and would also place the reason header into 
the new outgoing request.

A net effect of this is that the Reason header would be in the *new* URI 
in H-I, not in the *old* URI as is shown. To me that also makes more 
sense - its the reason this URI is present.

Bottom line - this should all make sense even without the use of H-I. 
Then H-I usage can also be folded into the examples to give an even more 
complete picture of what happened.

I also must say that I find the proposed cause text to be at best 
awkward. I'm not a grammarian, but ISTM that these terms are using the 
wrong part of speech - they don't sound like *causes*. And for that 
matter some of them don't sound like they are even related to 
retargeting. E.g. premium rate, vpn. I would expect that "The call was 
retargeted to number <number> because <cause>" would make sense for each 
of these.

	Thanks,
	Paul