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

<R.Jesske@telekom.de> Mon, 13 December 2010 08:41 UTC

Return-Path: <R.Jesske@telekom.de>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14093A6D73 for <sipcore@core3.amsl.com>; Mon, 13 Dec 2010 00:41:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level:
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6ADRKQ63ZZO for <sipcore@core3.amsl.com>; Mon, 13 Dec 2010 00:41:21 -0800 (PST)
Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 5C5C53A6D70 for <sipcore@ietf.org>; Mon, 13 Dec 2010 00:41:20 -0800 (PST)
Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 13 Dec 2010 09:42:53 +0100
Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.187]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Mon, 13 Dec 2010 09:42:52 +0100
From: <R.Jesske@telekom.de>
To: <HKaplan@acmepacket.com>, <mary.ietf.barnes@gmail.com>
Date: Mon, 13 Dec 2010 09:42:50 +0100
Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header
Thread-Index: AcuYidnmGLPCFE06Ri2g4olG/+Jk8wCFtdew
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D050E70A6@HE111648.emea1.cds.t-internal.com>
References: <CD5674C3CD99574EBA7432465FC13C1B2202288A06@DC-US1MBEX4.global.avaya.com> <4CDC04F2.3010701@cisco.com> <AANLkTi=utzFcqg_QTfurdB0WKK8MRAny8Pb8CEE=s60L@mail.gmail.com> <4CEC570D.8080700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se> <4CED9370.5010001@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se> <B11765B89737A7498AF63EA84EC9F5772378A7@ftrdmel1> <AANLkTimH+onHwUeYAYRmARXCzHe=nt_wknXRhwA7haUL@mail.gmail.com> <9DF7AC2B-667B-41CF-842D-1E3BC5724C71@acmepacket.com>
In-Reply-To: <9DF7AC2B-667B-41CF-842D-1E3BC5724C71@acmepacket.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D050E70A6HE111648emea1cd_"
MIME-Version: 1.0
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Reason as a parameter rather than an escaped header
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Dec 2010 08:41:22 -0000

Hi Hadriel,

for 1) I see this as a option which the service provider could choose. Not everybody will be mandated to put in a Reason on a internal event within the server which ends in a retargeting/diversion.
for 2) I think it could be a normal Reason value, based on a equivalent processes as it would be sent out by an other sever. E.G. If a timer expires a 408 could be included.

Best Regards

Roland


  _____

Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag von Hadriel Kaplan
Gesendet: Freitag, 10. Dezember 2010 17:47
An: Mary Barnes
Cc: sipcore@ietf.org WG
Betreff: Re: [sipcore] Reason as a parameter rather than an escaped header



OK, so I think there's general agreement to add additional H-I header fields for internal retargeting.

I have two questions then:

1) the text below says: "For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted."
Why is this a MAY?  What's the alternative?  Does it mean they may do something else, like use a RFC 4458 style cause URI parameter?  Does it mean they may associate it with a different hi-targeted-to-uri? (I assume not, but the text isn't clear)

For example, is this what you really want to say: "For retargets as a result of timeouts or internal events, a Reason MUST be associated with the hi-targeted-to-uri that has been retargeted and encoded as an embedded Reason header field in the URI, unless the reason for the retargeting is unknown."

2) What form of reason-value protocol can be used for a Reason from an internal operation?  Can it be a "SIP" cause?  Ultimately if this info is used by a receiver of the H-I entries to trigger different behavior/features, it would be really nice not to have to create a bunch more values that the receiver would have to understand/support.

-hadriel

On Dec 6, 2010, at 10:38 AM, Mary Barnes wrote:


Hi Marianne et al,

I totally agree that there was some text removed from RFC 4244 that was intended to handle the internal retargeting case. I would suggest we add that back, updating the paragraph to be a little more concise as I suggested earlier in the thread and add a note with regards the definition of any new Reason headers - something like the following:

  If the response contains any Reason header fields, then
  the Reason header fields MUST be captured as Reasons
  associated with the hi-targeted-to-uri that has been
  retargeted.  If the SIP response does not include a Reason header field
  (see [RFC3326]), the SIP  Response Code that triggered the retargeting
  MUST be included as the Reason associated with the hi-targeted-to-uri
  that has been retargeted.

  For retargets as a result of timeouts or internal events, a Reason
  MAY be associated with the hi-targeted-to-uri that has been
  retargeted.  [MB: this is the original text from RFC 4244.]

  In the case that additional Reason headers are defined, per RFC 3326,
  the use of these Reason headers for the History-Info header field
  MUST follow the same rules as described above.

Thanks,
Mary.


On Thu, Nov 25, 2010 at 4:33 PM, <marianne.mohali@orange-ftgroup.com<mailto:marianne.mohali@orange-ftgroup.com>> wrote:


Hi,

I agree that draft-mohali-sipcore-reason-extension-application could live independently of 4244bis, except for the section "Reason in the History-Info header" that should still allow wat is proposed in draft-reason.

Note that RFC4244 is compatible with the draft-reason proposal: As work on 4244bis was in progress, we based the draft on the following text from RFC4244: "For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted."

Unfortunately, this sentence disappeared and only the last sentence about timeout suggests to insert a Reason for an internal process.

If there is no objection, we could put this text back in 4244bis to keep explicit the ability to insert the Reason header field in a H-I entry for *internal* reasons (with a MAY).


Regards,
Marianne

> -----Message d'origine-----
> De : sipcore-bounces@ietf.org<mailto:sipcore-bounces@ietf.org>
> [mailto:sipcore-bounces@ietf.org<mailto:sipcore-bounces@ietf.org>] De la part de Christer Holmberg
> Envoyé : jeudi 25 novembre 2010 07:48
> À : Paul Kyzivat
> Cc : Worley, Dale R (Dale); sipcore@ietf.org<mailto:sipcore@ietf.org>
> Objet : Re: [sipcore] Reason as a parameter rather than an
> escaped header

>
>
> Hi,
>
> >>I think we should ask ourselves: assuming we allowed to do what
> >>Marianne is proposing, would anything break?
> >>
> >>Does anyone really care whether a H-I entry was inserted based on a
> >>"real" or "virtual" response? Aren't people more interested in the
> >>actual reason value?
> >
> >I don't currently see a problem with permitting this (though I'm
> >interested to hear if somebody else sees an issue).
> >
> >But IMO the current text doesn't suggest to me that this is valid.
> >So if the desire is for it to be valid it would be good to have some
> >text that makes it so.
>
> I agree. We would need to add some text.
>
> Regards,
>
> Christer
>

> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org<mailto:sipcore@ietf.org>
> https://www.ietf.org/mailman/listinfo/sipcore
>
_______________________________________________
sipcore mailing list
sipcore@ietf.org<mailto:sipcore@ietf.org>
https://www.ietf.org/mailman/listinfo/sipcore



<ATT00001..c>