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

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Nov 2010 14:00:30 -0400

[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

---

From: <[email-masked]>
Date: Mon, 8 Nov 2010 12:13:10 +0100

Hi Paul,

My response inline [MM]

Thanks,
Marianne 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Paul Kyzivat
> Envoyé : jeudi 4 novembre 2010 19:01
> À : SIPCORE
> Objet : [sipcore] draft-mohali-sipcore-reason-extension-application-00
> 
> [as individual]
> 
> 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.
> 
> 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.
[MM] RFC3326 (Reason header) states that it is possible the have several Reason values since the protocol values are different and an implementation is free to ignore Reason values that it does not understand. That's why we propose a new protocol value not to interfere with the real received SIP cause (if there is one).
> 
> 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.
[MM] But the reason why this last (new) URI is present is because the "old" one decides it. ISTM the important is who is responsible, who requests the retargeting. 
> 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.
[MM] I can reword the descriptive sentences. However, the signification is different from the one you propose. It's rather "The call processing has been influenced because of this <Application> processing".
The reason should not only available escaped in the H-I but also in a "normal" SIP message (eg. BYE, CANCEL).
But you're welcome to propose some text :)
By the way, I've noted few inconsistencies in the terms usage ("protocol-cause", "reason-params"..) so I will reword some sentences for the next version. 
> 
> 	Thanks,
> 	Paul
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>