Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 25 Nov 2010 23:48:19 +0100
Message-ID: <B11765B89737A7498AF63EA84EC9F5772378AA@ftrdmel1>
In-Reply-To: <3A8FC9BC-3112-492A-87C2-3B5290A2D36D@acmepacket.com>
Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header
Thread-Index: AcuMl99FA/lF6V1FR3y5kQR+r7oSCAAWVKMA
References: <CD5674C3CD99574EBA7432465FC13C1B2202288A06@DC-US1MBEX4.global.avaya.com><4CDC04F2.3010701@cisco.com><AANLkTi=utzFcqg_QTfurdB0WKK8MRAny8Pb8CEE=s60L@mail.gmail.com><4CEC570D.8080700@cisco.com>
 <3A8FC9BC-3112-492A-87C2-3B5290A2D36D@acmepacket.com>
From: <marianne.mohali@orange-ftgroup.com>
To: <HKaplan@acmepacket.com>, <pkyzivat@cisco.com>
Cc: dworley@avaya.com, sipcore@ietf.org
Subject: Re: [sipcore] Reason as a parameter rather than an escaped header
Precedence: list

 Hi,

My adding [MM]

Marianne

> -----Message d'origine-----
> De : sipcore-bounces@ietf.org=20
> [mailto:sipcore-bounces@ietf.org] De la part de Hadriel Kaplan
> Envoy=E9 : jeudi 25 novembre 2010 12:57
> =C0 : Paul Kyzivat
> Cc : Worley, Dale R (Dale); sipcore@ietf.org
> Objet : Re: [sipcore] Reason as a parameter rather than an=20
> escaped header
>=20
>=20
> On Nov 23, 2010, at 7:06 PM, Paul Kyzivat wrote:
>=20
> > But my remaining concern is about the rules in 4244bis=20
> regarding how=20
> > and when Reason headers are included in the H-I entries. It still=20
> > seems to me that the text only talks about including them due to a=20
> > response having been received. Where is the language that discusses=20
> > adding a reason when retargeting is performed for some reason=20
> > unrelated to a response?
> >=20
> > While I think one can argue that a server doing such=20
> retargeting can=20
> > imagine having sent the request to a virtual redirect=20
> server and then=20
> > processing the response from it, ISTM that would then call=20
> for adding=20
> > H-I entries for those steps.
>=20
> Right, that's the main piece to figure out first.  We already=20
> agreed that 4244bis tells proxies to create H-I entries for=20
> internal retargeting decisions.  What's not clear is what=20
> internal H-I entries have to be created, and whether the=20
> embedded Reason header value of the *SIP* type can be used=20
> for such cases.
>=20
> For example, suppose Alice called Bob, and proxy-1 internally=20
> diverts it to Charlie because it knows Bob is busy, *without*=20
> having to send the INVITE to Bob and getting a 486 response.
>=20
> Is it legit for the H-I look like this:
> History-Info: =
<sip:bob@example.com?Reason=3DSIP%3Bcause%3D486>;index=3D1
> History-Info: <sip:charlie@example.com>;index=3D1.1;mp=3D1
> History-Info: <sip:charlie@192.1.2.3>;index=3D1.1.1;rc=3D1.1
>=20
> Or does it have to look like this:
> History-Info: <sip:bob@example.com>;index=3D1
> History-Info: =
<sip:bob@127.0.0.1?Reason=3DSIP%3Bcause%3D486>;index=3D1.1
> History-Info: <sip:charlie@example.com>;index=3D1.2;mp=3D1
> History-Info: <sip:charlie@192.1.2.3>;index=3D1.2.1;rc=3D1.2
>=20
> Or does it have to do something like this:
> History-Info:=20
> <sip:bob@example.com?Reason=3DInternal%3Bcause%3D486>;index=3D1
> History-Info: <sip:charlie@example.com>;index=3D1.1;mp=3D1
> History-Info: <sip:charlie@192.1.2.3>;index=3D1.1.1;rc=3D1.1
>=20
[MM] Or (as per 3GPP CDIV 24.604 for call forwarding busy)
History-Info: <sip:bob@example.com>;index=3D1
History-Info: <sip:charlie@example.com;cause=3D486>;index=3D1.1;mp=3D1
History-Info: <sip:charlie@192.1.2.3>;index=3D1.1.1;rc=3D1.1

> -hadriel
>=20
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>=20