Subject: RE: [Sip] Updated connected-identity draft

From: "Elwell, John" <[email-masked]>
Date: Tue, 07 Mar 2006 09:49:25 +0000

Ilan,
 
See below.
 
John

  _____  

From: Ilan Avner [mailto:[email-masked]] 
Sent: 06 March 2006 20:06
To: Elwell, John; Alexeitsev, D
Cc: [email-masked]
Subject: RE: [Sip] Updated connected-identity draft

Hi all,
I have two questions regarding the identity draft:
 
1.Does the new draft address a feature implemented on the PSTN world called
COLR (Connected number presentation restriction), this feature is about
sending the connected number as a restricted number.
the solution for sending restricted numbers as the calling number (in the
first INVITE) is to use the p-asserted header, what about the connected
number?
[JRE] The Identity header defined in the sip-identity draft already makes
provision for anonymous users, and with my draft that provision can be
applied equally to connected users.
 
2.In case the called number had changed after sending 180, as I understand
the UAS should send an UPDATE request with the new number in the from
header.
what about the 200 O.K for the INVITE, should the To header also change to
reflect the new called number or should be the same as the To header sent in
the 180?
[JRE] That is an open issue in the draft - opinions are welcome. 
 
Thanks.
 
Ilan.

  _____  

מאת: Elwell, John [mailto:[email-masked]]
נשלח: ב 06/03/2006 18:35
אל: Alexeitsev, D
עותק לידיעה: [email-masked]
נושא: RE: [Sip] Updated connected-identity draft

Denis,
 
The disadvantage with changing the To header field URI in the INVITE
response is that authentication using the Identity header cannot be
achieved. It may be possible to rely on other means to ensure the
authenticity of this information (e.g., SIPS + transitive trust +use of TLS
on the last hop too). It depends whether there is sufficient interest from
the community in this.
 
John

  _____  

From: Alexeitsev, D [mailto:[email-masked]] 
Sent: 06 March 2006 13:57
To: Elwell, John
Cc: [email-masked]
Subject: AW: [Sip] Updated connected-identity draft

Hello Jonh
 
Referring to the open issue about the updated To: header in the final INVITE
response:
 
Would it not be possible to have a general solution that would allow both
the change of the To: header URI in the final INVITE response, if the COLP
information is available at that time, and the midcall change using the
UPDATE method?
 
The tests we made with several SIP hard and soft phones show, that the
current implementations would accept the changed To: header URI in the final
INVITE response without any session influence. The changed To: header URI
information would currently not be presented to the user by the UACs, but
this is a user interface issue without protocol impact.
 
In the subsequent requests the UACs would still use the original To: header
URI, so this could be mentioned in the draft to increase the
interoperability with current implementations.
 
Greetings,
Denis Alexeistev
-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]] 
Gesendet: Montag, 6. März 2006 11:50
An: [email-masked]
Betreff: [Sip] Updated connected-identity draft

draft-elwell-sip-connected-identity is now available: 
 
<http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-01.
txt>
http://www.ietf.org/internet-drafts/draft-elwell-sip-connected-identity-01.t
xt 

Compared with the 00 version, this has changed considerably and is intended
to reflect decisions made in Vancouver. It exploits the ability to change
the From URI during a dialog, so that requests in the reverse direction can
place the source URI in the From header field and the Identity header can be
used to provide authentication, rather having to introduce new headers.
Comments would be appreciated. I would like to get this adopted as a SIP WG
item in Dallas.

John 

_______________________________________________
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: "Alexeitsev, D" <[email-masked]>
Date: Tue, 7 Mar 2006 13:25:53 +0100

Hello John
 
see inline

2.In case the called number had changed after sending 180, as I understand the UAS should send an UPDATE request with the new number in the from header.
what about the 200 O.K for the INVITE, should the To header also change to reflect the new called number or should be the same as the To header sent in the 180?
[JRE] That is an open issue in the draft - opinions are welcome.  
 
As I said before, I think, that changing the To: header URI in the 200 Ok aligns nicely with the UPDATE procedure and additionally would also support the trust domain scenario.
 
In this case the proposed procedure would gain much wider acceptance.
 
Greetings,
Denis Alexeitsev

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Mar 2006 14:13:10 +0200

Hi,

Currently, you are not allowed to change the value of the To header in an UPDATE either.

>From a pure SIP protocol perspective only the tag is used for dialog identification, so changing the "phone number" part should have no core impacts - but some implementations may of course always check the whole header.

And, if one were allowed to change the phone number part (not only from 180 to 200, but also in other cases), would some of the existing extension/P- headers be made obselete?

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 08 Mar 2006 21:32:30 +0000

Christer,

The agreement in Vancouver concerned changing the URI in the From header
mid-dialog. In my opinion changing the URI in the To header mid-dialog (or
even in a dialog-forming response) is a similar issue and might also be
acceptable to the community.

John 

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 08 March 2006 12:13
> To: Alexeitsev, D; Elwell, John
> Cc: [email-masked]; [email-masked]
> Subject: Re: AW: [Sip] Updated connected-identity draft
> 
> Hi,
> 
> >From a pure SIP protocol perspective only the tag is used 
> for dialog identification, so changing the "phone number" 
> part should have no core impacts - but some implementations 
> may of course always check the whole header.
> 
> And, if one were allowed to change the phone number part (not 
> only from 180 to 200, but also in other cases), would some of 
> the existing extension/P- headers be made obselete?
> 
> Regards,
> 
> Christer
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Mar 2006 23:50:21 +0200

Hi,

So, to clarify: this would mean that any node, at any time, is allowed to change the URI in the To- and From headers?

Or, are we defining some special situations when it's allowed?

Regards,

Christet

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 08 Mar 2006 22:18:17 +0000

Christer,

This was agreed for further exploration as the solution to the
connected-identity problem, rather than the other solutions on the table at
the time. However, the discussion really only concerned the From header URI,
not the To header URI. Hence the open issue in the current
connected-identity draft concerning the To header URI.

John 

> Sent: 08 March 2006 21:50
> Subject: RE: AW: [Sip] Updated connected-identity draft
> 
> Hi,
> 
> So, to clarify: this would mean that any node, at any time, 
> is allowed to change the URI in the To- and From headers?
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 09 Mar 2006 11:16:44 +0000

Frank,

Thanks for your comments. See my responses below.

John 

> From: Frank Derks [mailto:[email-masked]] 
> Sent: 09 March 2006 09:23
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sip] Updated connected-identity draft
> 
> John,
> 
> I had a look at the new draft and would like to make a few comments.
> 
> - In section 3 you provide an example of a transfer ("Parties 
> involved...").
>   Possibly, I am missing something, but I don't see how the example
>   relates to this draft. 
[JRE] On receipt of a REFER request from A, B sends an INVITE request to C.
B's identity can be in the From header of the INVITE request and can be
authenticated by means of an Identity header. But how does B obtain C's
identity, which will not necessarily be the same as that in the To header of
the INVITE request?

> 
> - It might be a good idea to move section 4 to section 9, because it
>   relates to security aspects.
[JRE] No, I prefer to keep the existing order, because section 4 provides
much of the motivation for what follows. Section 9 covers security
considerations relating to the new material in this I-D, not security
considerations relating to existing capabilities.

> 
> - In section 5 you write about the "response identity problem". Are
>   you referring to the fact that it is difficult to authenticate 
>   identities in responses?
[JRE] Yes, 
> 
> - The "OPEN ISSUE" in section 5, re-states something that was said
>   earlier in the same section ("Note that it might also ..."). It 
>   would seem that this earlier statement removes the need to keep
>   this issue open.
[JRE] Not really - I am not sure there is community agreement yet.

> 
> - In 6.1/6.2/6.3 there are several occasions in which a "MUST" might 
>   be more appropriate than a "SHOULD" and a "SHOULD" than a "MAY": 
> 
>     6.1:
>     "... the UPDATE method [4] SHOULD ..." -> "MUST"?
[JRE] Yes, I tend to agree.

>     "... the re-INVITE method SHOULD ..." -> "MUST"?
[JRE] Yes, I tend to agree.

>     "... the UA MAY ..." -> "SHOULD"?
[JRE] I am not sure we should mandate indicating information to the user -
that is an internal matter for the UA. Perhaps it should be "may" instead of
"MAY".

> 
>     6.2:
>     "... on that dialog, the UA MAY..." -> "SHOULD"?
[JRE] Ditto
> 
>     6.3:
>     "... on that dialog, the UA MAY ..." -> SHOULD?
[JRE] Ditto
> 
> - In 6.1 you raise an appropriate open issue. My two cents: for 
>   consistency's sake (see also the 4th paragraph in 6.2), I would
>   say that this is indeed a good idea.
[JRE] Yes, comments to date seem to support this.
 
> 
>   In the same piece of text you say something about the SDP that
>   might have to be included in the UPDATE. When this is indeed 
>   required, it also becomes necessary to say something about what
>   this SDP has to look like. RFC3311 is not at all clear about
>   the scope of UPDATE. UPDATE is said to be a "target refresh
>   request", but the definition of this is rather loose: "a 
>   request that can modify the remote target of the dialog". What
>   does "modify" mean in this context?
[JRE] It means change the Contact URI.

> 
> Cheers,
> 
> Frank
> 
> 
> 
> 
> 
> 
> 
> 
> "Elwell, John" <[email-masked]> 
> 2006-03-06 11:50 AM
> 
> To
> [email-masked]
> cc
> 
> Subject
> [Sip] Updated connected-identity draft
> Classification
> 
> 
> 
> 
> 
> 
> 
> http://www.ietf.org/internet-drafts/draft-elwell-sip-connected
> -identity-01.txt 
> 
> Compared with the 00 version, this has changed considerably and is 
> intended to reflect decisions made in Vancouver. It exploits 
> the ability 
> to change the From URI during a dialog, so that requests in 
> the reverse 
> direction can place the source URI in the From header field and the 
> Identity header can be used to provide authentication, rather 
> having to 
> introduce new headers. Comments would be appreciated. I would 
> like to get 
> this adopted as a SIP WG item in Dallas.
> John _______________________________________________