RE: [Sipping-tispan] Requirements 02e

"Bemmel, Jeroen van (Jeroen)" <jbemmel@lucent.com> Fri, 23 September 2005 11:18 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlZk-00053p-3k; Fri, 23 Sep 2005 07:18:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlZh-00053f-D2 for sipping-tispan@megatron.ietf.org; Fri, 23 Sep 2005 07:18:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08224 for <sipping-tispan@ietf.org>; Fri, 23 Sep 2005 07:18:40 -0400 (EDT)
Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIlg7-0003Qx-V2 for sipping-tispan@ietf.org; Fri, 23 Sep 2005 07:25:20 -0400
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8NBHTQ0019137; Fri, 23 Sep 2005 06:17:29 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <SQW8KN9W>; Fri, 23 Sep 2005 13:17:28 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550577DFD6@nl0006exch001u.nl.lucent.com>
From: "Bemmel, Jeroen van (Jeroen)" <jbemmel@lucent.com>
To: "'Jesske, R'" <R.Jesske@t-com.net>, "'pkyzivat@cisco.com'" <pkyzivat@cisco.com>, "'Miguel.An.Garcia@nokia.com'" <Miguel.An.Garcia@nokia.com>
Subject: RE: [Sipping-tispan] Requirements 02e
Date: Fri, 23 Sep 2005 13:17:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Content-Transfer-Encoding: quoted-printable
Cc: "'sipping-tispan@ietf.org'" <sipping-tispan@ietf.org>
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN <sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org

A similar issue: What happens in case of call transfer? Would the other end receive updated additional identity information?

JvB

> -----Original Message-----
> From: Bemmel, Jeroen van (Jeroen) 
> Sent: Friday, September 23, 2005 1:12 PM
> To: 'Jesske, R'; Bemmel, Jeroen van (Jeroen); pkyzivat@cisco.com;
> Miguel.An.Garcia@nokia.com
> Cc: sipping-tispan@ietf.org
> Subject: RE: [Sipping-tispan] Requirements 02e
> 
> 
> Roland,
> 
> In case of diverted communication, the To header retains its 
> original value. 
> 
> In any case, (in my mind at least) a callee accepting a call 
> would add this information (header or parameter) to the 2xx 
> response (e.g. to INVITE), so the caller would get 
> information provided by the UA that is answering, not always 
> the one that he originally called. 
> 
> If this was not intended, then perhaps this is something to 
> clarify in the requirements. But whether a header or a 
> parameter would be used, I don't think there's a difference 
> w.r.t. the issue you mention
> 
> Regards,
> 
> Jeroen
> 
> 
> > -----Original Message-----
> > From: Jesske, R [mailto:R.Jesske@t-com.net]
> > Sent: Friday, September 23, 2005 12:50 PM
> > To: jbemmel@lucent.com; pkyzivat@cisco.com; 
> Miguel.An.Garcia@nokia.com
> > Cc: sipping-tispan@ietf.org
> > Subject: AW: [Sipping-tispan] Requirements 02e
> > 
> > 
> > In principle I have nothing against such an approach.
> > But what is in the case of diverting the communication.
> > So that the to header is different from the 
> > P-Asserted-Identity and the identity in the to header belongs 
> > not to the user where the communication was sent to originally?
> > 
> > Roland
> > 
> > > -----Ursprüngliche Nachricht-----
> > > Von: Bemmel, Jeroen van (Jeroen) [mailto:jbemmel@lucent.com] 
> > > Gesendet: Freitag, 23. September 2005 12:34
> > > An: Jesske, Roland; pkyzivat@cisco.com; Miguel.An.Garcia@nokia.com
> > > Cc: sipping-tispan@ietf.org
> > > Betreff: RE: [Sipping-tispan] Requirements 02e
> > > 
> > > 
> > > > So we want the have the same within SIP. In forward direction 
> > > > we have the From header and the P-Asserted-Identity. But in 
> > > > Backward direction the equivalent to the From header is missing.
> > > > 
> > > > So we need such an identity header for the backward direction 
> > > > setup from the callee.
> > > > 
> > > > Roland
> > > 
> > > What if the callee would simply add a parameter to the To 
> > > header? Something like
> > > To: 
> > > 
> <sip:callee@provider.com>;tag=25425741;identity=user@altprovider.com
> > > 
> > > Jeroen
> > > 
> > 
> 

_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan