Subject: [Sip] comments on connected-identity

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Nov 2006 23:21:38 -0500

Apologies that these come after the conclusion of WGLC.

> used to indicate a change of identity during a dialog, e.g., because 
> of some action in a Public Switched Telephone Network (PSTN) behind a
>  gateway.

I think you mean, "in the Public..."

> SIP (RFC 3261 [1]) initiates sessions but it also provides 
> information on the identities of the parties at both ends of a 
> session.  Users need this information to help determine how to deal 
> with communications initiated by SIP.  As a call proceeds, these 
> identities may change.  This can happen for many reasons: calls are 
> forwarded, calls are parked and picked up, calls are transferred, 
> calls are queued to be picked up by a pool of agents, and so on.

This text mixes what I think are two very different use cases. In
forwarding-related applications, its not that the identity of the party
changes (since it doesn't), but that the request eventually arrives at
an entity that is different than the one originally targeted by the
caller. That is quite distinct from the case where, due to a transfer on
the PSTN side, the identity of a party on the call changes.

I'd also note that the need for this in applications such as agent pools
and call park depends entirely on how those work; solutions which use
INVITE/Replaces or which purposefully obfuscate the identity of the
called party do not need this mechanism.

> This document extends the use of the From header field to allow it to
>  convey "connected identity" information (the identity of the 
> connected user) in either direction within the context of an existing
> 
> 
> 
> 
> Elwell                    Expires April 8, 2007                 [Page
> 3]  Internet-Draft              SIP Connected ID
> October 2006
> 
> 
> INVITE-initiated dialog.

Is there a reason this is limited to INVITE-initiated dialogs? There are
use cases for SUBSCRIBE (though admittedly more corner cases).

> o  the identity of a user that replaces the caller or callee 
> following a call re-arrangement such as call transfer.

I'd like to clarify here that this is referring to transfer where one
side is on the PSTN. Our standards-based techniques for transfer do not
suffer this problem.

> The provision of the identity of the responder in a response 
> ("response identity") is outside the scope of this document.

I think its worth two sentences that explains why; I can just imagine
implementors asking why they need to send another reuqest when they can
just modify the To in the response.

> A mid-dialog request is used to provide connected identity.  The UAC 
> for that request inserts its identity in the From header field of the
>  request and the Identity header field (RFC 4474 [3]) can be used to 
> provide authentication.

This second sentence makes it sound like its the UAC thats inserting the
Identity header field. Suggest ending the sentence at "..of the request."

> The Identity header field is inserted by a suitable Authentication
> Service on the path of the mid-dialog request, typically at a proxy
> that record routes and is able to authenticate the UAC.

"typically" isn't strong enough; indeed there is a requirement that the
proxy providing the authtnication service has to record-route. Suggest
removing "typically".

> This solution uses the UPDATE method (RFC 3311 [4]) for the
>    additional request.  

Careful; this makes it sound like its JUST update. But its not; a 
re-INVITE can also be used.

> To send the potential callee identity the UAS for the INVITE request
> sends the UPDATE request after sending a reliable 1xx response to the
>  INVITE request and after receiving a PRACK request and responding to
>  it.

This is very hard to parse. I think you mean that the UAS has to wait
until it receives a PRACK for a reliable provisional response it sent.
The text needs to be clearer that you actually have to implement RFC
3262 if you want to provide called party identity prior to answer.

> It is assumed that deployed
>    proxies will already be able to tolerate a change of URI, since this
>    has been expected for a considerable time.  To cater for any UAs that
>    are not able to tolerate a change of URI, a new option tag "from-
>    change" is introduced for providing a positive indication of support
>    in the Supported header field.  

These two sentences are somewhat contradictory. The first says that its 
been long enough that this is not a problem anymore for proxies. If so, 
why is it a problem for UAs which require an option tag?

I'm curious if we have evidence of any deployed UA at this point that 
would break by a change in URI.

I'm not objecting to the option tag; I just want to make sure we really 
have a need for it.

> In the absence of a suitable Authentication Service on the path of
>    the mid-dialog request, the UAS will receive an unauthenticated
>    connected identity (i.e., without a corresponding Identity header
>    field).  The implications of this are discussed in section Section 7

Double section.

>  After an early dialog has been formed (after sending a reliable
>    provisional response the INVITE request), 

to the INVITE request

> if the "from-change" option
>    tag has been received in a Supported header field, the UA MAY issue
>    an UPDATE request [4] on the same dialog.  

Your text in the overview requires the UA to wait for the PRACK.

> been formed (after sending a 2xx provisional response the INVITE
>    request), 

2xx is final, not provisional.

> fter a full dialog has
>    been formed (after sending a 2xx provisional response the INVITE
>    request), if the "from-change" option tag has been received in a
>    Supported header field and an UPDATE request has not already been
>    sent on the early dialog, the UA MUST issue an UPDATE request on the
>    same dialog.  In either case the UPDATE request MUST contain the
>    callee's (or potential callee's) identity in the URI of the From
>    header field (or an anonymous identity if anonymity is required).

I find the "MUST send UPDATE" questionable here. I reserve MUST for 
things which break if you don't do them. Clearly, nothing breaks here if 
you don't do this. So I don't think you can do more than SHOULD here.

> field of subsequent mid-dialog requests and MUST also continue to be
>    prepared to receive the old URI at least until a request containing
>    the revised URI has been received.

the revised URI in the To header field

> After receiving a 2xx response to a request with a revised URI in the
>    From header field (i.e., revised compared to the URI sent in the From
>    header field of the previous request on this dialog or in the To
>    header field of the received dialog-forming INVITE request if no
>    request has been sent), the UA MUST send the same URI in the From
>    header field of any future requests on the same dialog, unless the
>    identity changes again.

what about before the 2xx is received? For example a pipelined request?

I think the rule here is actually much simpler - you include, in the 
 From header field, your "current identity", whatever that is, and NOT 
the local URI from the dialog state as described in RFC 3261.

The rules in this section omit any guidance on the To header field. I 
think you have to say that you include the current remote identity of 
the peer, where that current identity is now being updated based on the 
rules in section 4.4.2, rather than being fixed at the beginning of the 
dialog as in RFC 3261.

> Note that this involves terminating the dialog.  To avoid this, it
>       is recommended in section Section 4.6 that a Verifier should avoid

double section

>  From header field URI differs from that received in the previous
>    request on that dialog or that sent in the To header field of the
>    original INVITE request and if the UA sends a 2xx response, the UA
>    MUST use this revised URI in the To header field of any future
>    requests it sends on the same dialog (irrespective of whether the
>    received identity is supported by a valid signature).

Well yes, except that this section is about receiving requests, not 
sending them.

What you should say is that the remote URI, defined in RFC 3261 as part 
of the dialog state, MUST be updated with the value of the From header 
field in the request. Thats it. That update can be done regardless of 
whether it differs from the previous one; its just a no-op if they are 
the same. This allows you to simplify the rule here.

> A proxy that record routes during an INVITE request MUST be tolerant
>    of changes of the From header field URI compared with that in the
>    initial INVITE request for mid-dialog requests in the same direction
>    as the INVITE request and MUST be tolerant of changes of the From
>    header field URI compared with the To header field URI in the initial
>    INVITE request for mid-dialog requests in the opposite direction.

This is a bit hard to follow.

Suggest:

A proxy that receives a mid-dialog request MUST be prepared for either 
to the To or From header field URI to differ from those that appeared in 
the dialog forming request or response.

> A proxy that is able to provide an Authentication Service or a
>    Verifier for mid-dialog requests MUST record route if Supported:
>    from-change is indicated in the dialog forming request.

I think this rule is really just for authentication services. If the 
verifier is in the UA clearly it doesn't need to record-route.

> In the examples the domain example.com is assumed to have the
>    following private key rendered in OpenSSL format). 

missing open bracket.

In the examples section:

* message 2 should have the Max-Forwards decremented by 1 (to 69)
* same with message 6, 8
* all messages with Identity - please use the <alloneline> technique 
from Roberts torture test draft so that you can line fold for readability.

> 5.2.  Sending revised connected identity during a call
> 
>    In this example a call is established between Alice and Bob, where
>    Bob (not shown) lies behind a B2BUA.  Bob's identity is conveyed by
>    an UPDATE request.  Then call transfer occurs in the B2BUA, such that
>    Alice becomes connected to Carol (also not shown), and a re-INVITE
>    request is issued allowing the session to be renegotiated.  The B2BUA
>    provides the Authentication Service and thus generates the Identity
>    header field in the re-INVITE request to provide authentication of

I don't want to encourage b2bua and this form of transfer, so I'd prefer 
that this section be recast as using a pstn gateway.

> A.2.  Existing methods for providing authenticated identity information

This appendix doesn't really add much value. I'd suggest removing it.

If anything, the main question folks will have is why not just use 
P-A-ID in the 18x or 2xx. As you may know despite RFC 3325 rules that 
say this is not allowed, IMS has gone ahead and specified that anyway 
for connected identity.

Thanks,
-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Nov 2006 14:01:50 -0500

Jonathan Rosenberg wrote:

>> o  the identity of a user that replaces the caller or callee following 
>> a call re-arrangement such as call transfer.
> 

...

> that this section be recast as using a pstn gateway.

While there is another way of doing transfer, and I certainly don't 
advocate including a B2BUA in a call for the sole purpose of doing 
transfers, there *are* reasonable uses for this kind of topology. For 
instance it is quite appropriate for "click to dial" scenarios. So I do 
think it is appropriate to acknowledge the case.

(Its not the B2BUA that is bad, it is the improper use of a B2BUA that 
is bad. Somehow that sounds familiar. :-)

		Paul