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

Hi Paul,

My response inline [MM]

Thanks,
Marianne 

> -----Message d'origine-----
> De : sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] 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]
> 
> 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.
[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. 
> 
> 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.
[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
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 