Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 3 Apr 2006 22:42:11 +0200

Hi John,

Inline. 

>1. Proxy impacts: There are no words on how the chaning of the URI 
>will impact intermediate proxies (see separate thread). Normally our 
>documents contains a "proxy impacts", but not in this. And, there is 
>no agreed solution, so I consider that issue both MISSING TEXT and 
>TECHNICAL.
[JRE] Missing text can and will be added - I am already drafting it. The
main technical issue (i.e., needing to accommodate change of URI
mid-dialog, as anticipated in RFC3261) has been agreed since the
face-to-face in Vancouver. I don't see any other technical issue for
proxies (other than the impact on an authentication service, which is
minor in that it just means the Authentication Service can operate in
circumstances where previously it was unable to operate).

[CHH] The impact is that a RFC2543 uses, as far as I know, the whole To
header (not only the tag) to identify a dialog. So, if you send an
UPDATE with a new To header URI, such proxy will not recognize the
dialog.

Now, if you are saying that we don't need to take backward compability
into consideration I don't agree with the statement that chaning the To
header URI in a response would break any transaction rules. Because, as
I said earlier, the To header URI is not used for transaction
identification in RFC3261. [/CHH]

>2. Interworking (e.g. with PSTN): As was mentioned by Roland, this 
>causes problems with interworking, ie it is not "backward compatible"
>with the RFCs we have on interworking. Since we normally, when we 
>define extension, try to consider existing extensions and drafts/RFCs 
>I think we shall do it also in this case - even if some individuals 
>(those thinking PSTN will be replaced by IP overnight) probably don't 
>care. So, I also consider that part both MISSING TEXT and TECHNICAL.
[JRE] I consider specifying interworking with PSTN to be outside the
scope of this draft (an indeed outside the scope of all work items other
than those specifically aimed at PSTN interworking).

[CHH] I am not asking you to document PSTN interworking in the draft. I
am saying that draft won't work with our current PSTN interworking
specifications. Has there been a decission that we don't need to care
about that? [/CHH]

>Introducing the ability to convey connected identity IMPROVES
interworking with PSTN compared with the situation at 
>present, because firstly connected identity can be conveyed on
establishment of a call to PSTN, and secondly a change of 
>connected identity can be conveyed mid-call.

[CHH] Ok, so if you think it improves interworking, how are you going to
signal the mid-call change in PSTN, after you've sent CON/ANM (which the
200 OK triggers)? [/CHH]

>I admit that conveying connected identity during call establishment
from PSTN to SIP is more difficult than in the 
>opposite direction, but that does not make it worse than the present
situation. I see no reason to block something that 
>is useful just because it does not handle every situation when there is
no proposed solution that is acceptable and 
>solves all situations.

[CHH] Personally I think that a solution that does not handle the
interworking situation makes the solution pretty much unusable -
especially in networks where interworking occurs. Someone may say the
number of those networks is so small that we don't have to take that
use-case into consideration, but personally I disagree. [/CHH]

>Response identity, apart from not having a solution that finds favour
with the broader community, is unsuitable for mid-
>dialog changes of identity.

[CHH] I am not saying that we shall disallow using UPDATE to change the
identity mid-call, as currently defined (you wouldn't need to interwork
that into PSTN, I believe). I am asking for the possibility to also
change it in responses, in order to make it useful also with PSTN
interworking. [/CHH]

>I also disagree on the face-to-face decission that race condition is 
>not an issue. However, I realize that is maybe more an 
>deployment/use-case issue whether you can expect the UAC to send an 
>UPDATE/re-INVITE soon after it has received 200 OK for the initial 
>INVITE.
[JRE] I am sure we can work out the details of this as the work item
progresses. I don't see this as a blocking point.

[CHH] My intention is not to block. I was asked about what my issues
are, and I listed them :)

Regards,

Christer

> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Christer Holmberg (JO/LMF)
> > [mailto:[email-masked]]
> > Sent: 31 March 2006 13:08
> > To: Drage, Keith (Keith); [email-masked]
> > Subject: RE: [Sip] draft-elwell-sip-connected-identity-01.txt
> > 
> > 
> > 
> > Hi Keith,
> > 
> > I sent a mail within the "comments on sip-connected-identity" 
> > thread. I
> > presented some issues with the current solution, but also
> pointed out
> > that the draft currently does not talk about proxy impacts.
> > 
> > Regards,
> > 
> > Christer
> > 
> >  
> > 
> > -----Original Message-----
> > From: Drage, Keith (Keith) [mailto:[email-masked]]
> > Sent: 26. maaliskuuta 2006 19:25
> > To: [email-masked]
> > Subject: [Sip] draft-elwell-sip-connected-identity-01.txt
> > 
> > (As chair)
> > 
> > At the face-to-face meeting at IETF 65 we agreed that 
> > http://www.ietf.org/internet-drafts/draft-elwell-sip-connected
> -identity-
> 01.txt formed the basis of part of our charter milestone to provide 
> "Mechanism for Response Identity to IESG (PS).
> 
> This mail is to confirm that decision using the list. If you have 
> issues with this decision, please respond to this mail.
> 
> Note: Please keep responses to this thread entirely separate to the 
> thread on draft-cao-sip-response-identity
> 
> regards
> 
> Keith
> 
> Keith Drage
> [email-masked]
> 
> 
> _______________________________________________
> 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
> 
> _______________________________________________
> 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
> 
> _______________________________________________
> 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
> 

_______________________________________________
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

_______________________________________________
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