AW: [Sipping-tispan] Requirements 02e

Jeroen,
The Connected Number here P-Asserted-Identity in the Response of the connected UA and the additional connected identity must be from the user that is reached. And not that what was dialled. That was why this feature was defined within the PSTN/ISDN.

Roland 

> -----Ursprüngliche Nachricht-----
> Von: Bemmel, Jeroen van (Jeroen) [mailto:jbemmel@lucent.com] 
> Gesendet: Freitag, 23. September 2005 13:17
> An: Jesske, Roland; 'pkyzivat@cisco.com'.com'; 'Miguel.An.Garcia@nokia.com'
> Cc: 'sipping-tispan@ietf.org'
> Betreff: RE: [Sipping-tispan] Requirements 02e
> 
> 
> 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