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

<> Mon, 08 November 2010 11:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C863B28C15A for <>; Mon, 8 Nov 2010 03:33:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m+In4c4B4cYn for <>; Mon, 8 Nov 2010 03:33:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0183228C14E for <>; Mon, 8 Nov 2010 03:33:22 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 0E6458580A0; Mon, 8 Nov 2010 12:37:43 +0100 (CET)
Received: from (unknown []) by (Postfix) with ESMTP id 28EF37D80C3; Mon, 8 Nov 2010 12:17:54 +0100 (CET)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 12:13:12 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 8 Nov 2010 12:13:10 +0100
Message-ID: <B11765B89737A7498AF63EA84EC9F57715A9A8@ftrdmel1>
In-Reply-To: <>
Thread-Topic: [sipcore] draft-mohali-sipcore-reason-extension-application-00
Thread-Index: Act8Si6R1956EIPOTQGaDMmgtnj8iQArl5hw
References: <>
From: <>
To: <>, <>
X-OriginalArrivalTime: 08 Nov 2010 11:13:12.0749 (UTC) FILETIME=[EEDA9DD0:01CB7F35]
Subject: Re: [sipcore] draft-mohali-sipcore-reason-extension-application-00
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Nov 2010 11:33:24 -0000

Hi Paul,

My response inline [MM]


> -----Message d'origine-----
> De : 
> [] De la part de Paul Kyzivat
> Envoyé : jeudi 4 novembre 2010 19:01
> 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