Subject: [sipcore] <identity> element in RFC 4235

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 26 Mar 2010 16:51:50 +0100

Hello,

Let's suppose that Alice called Bob and Bob forwarded the call to Cecil which accepted the call.
When Alice's UE sent the INVITE, the To header was set to Bob's SIP URI (sip:[email-masked]).
Cecil's network provided P-Asserted-Identity header set to Cecil's SIP URI (sip:[email-masked]) in 2xx response.

Now Duren subscribes to dialog event package at Alice's UE.
Alice's UE generates dialog event package notification including the created dialog.

Is the <identity> element of the <remote> element of the created dialog supposed to contain:
1) the original To header field URI (sip:[email-masked]);
2) the true identity of the participant (sip:[email-masked]); or
3) none of them?

RFC4235 states:

-----------------------------------------------------------------------------------------------------
4.1.6.1.  Identity Element

   The "identity" element indicates a local or remote URI, as defined in
   [2] as appropriate.  It has an optional attribute, display, that
   contains the display name from the appropriate URI.

      Note that multiple identities (for example a sip: URI and a tel:
      URI) could be included if they all correspond to the participant.
      To avoid repeating identity information in each request, the
      subscriber can assume that the identity URIs are the same as in
      previous notifications if no identity elements are present in the
      corresponding local or remote element.  If any identity elements
      are present in the local or remote part of a notification, the new
      list of identity tags completely supersedes the old list in the
      corresponding part.

      <identity display="Anonymous">
           sip:[email-masked]</identity>
-----------------------------------------------------------------------------------------------------

remote URI as defined in [2] (RFC3261) is the original To header field URI (sip:[email-masked]).
However, the original To header field URI does not correspond to the true remote participant (sip:[email-masked]).
Does "as appropriate" have any particular meaning?

Thanks for clarification.

Kind regards

Ivo Sedlacek

Ericsson
Technology and Portfolio Management, Terminal Standardization
Sweden
Office: +46 10 711 9382
Fax: +46 10 713 5929
[email-masked]
www.ericsson.com

[http://www.ericsson.com/shared/images/Email.gif]

This communication is confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Mar 2010 12:32:13 -0400

[as individual]
comment at end...

Ivo Sedlacek wrote:
> Cecil's network provided P-Asserted-Identity header set to Cecil's SIP 
> URI (sip:[email-masked]) in 2xx response.
>  
> However, the original To header field URI does not correspond to the 
> true remote participant (sip:[email-masked]).

You mention Cecil's PAI being returned in the 2xx. The semantics of that 
are not defined in ietf. (I believe this usage *is* defined in IMS.)

RFC 4916 (connected identity) defines a mechanism to deliver that back 
to the caller in a request. If 4916 is used, the actual remote identity 
that is part of dialog state according to 3261 will be changed, and 
presumably will then be reported in the notify.

The impact of PAI on returns from the dialog event package is, AFAIK, 
undefined. (Does IMS define it?)

	Thanks,
	Paul

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 30 Mar 2010 08:11:24 +0200

See comment at the end.

Kind regards

Ivo Sedlacek

Ericsson
Technology and Portfolio Management, Terminal Standardization Sweden
Office: +46 10 711 9382
Fax: +46 10 713 5929
[email-masked]
www.ericsson.com

This communication is confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer

-----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 26. března 2010 17:32
> To: Ivo Sedlacek
> Cc: [email-masked]
> Subject: Re: [sipcore] <identity> element in RFC 4235
>
> [as individual]
> comment at end...
>
> Ivo Sedlacek wrote:
> > Hello,
> >
> You mention Cecil's PAI being returned in the 2xx. The semantics of that are not
> defined in ietf. (I believe this usage *is* defined in IMS.)
>
> RFC 4916 (connected identity) defines a mechanism to deliver that back to the caller
> in a request. If 4916 is used, the actual remote identity that is part of dialog
> state according to 3261 will be changed, and presumably will then be reported in
> the notify.
>
> The impact of PAI on returns from the dialog event package is, AFAIK, undefined.
> (Does IMS define it?)
>
>       Thanks,
>       Paul

IMS (so far) does not define any further rules above RFC 4235 on what to put in the dialog event package notification body.