Subject: RE: [Sip] UPDATE and P-Asserted-ID

From: "Henry Chen" <[email-masked]>
Date: Wed, 7 May 2003 09:57:02 -0500

I agreed and sometimes Update is better than re-Invite if we need to avoid mid-dialog media session changes.

Thanks,

Henry

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, May 07, 2003 4:20 AM
> To: [email-masked]'
> Subject: [Sip] UPDATE and P-Asserted-ID
> 
> 
> In RFC3325 section 9.1 it indicates that P-Asserted-ID is not 
> allowed in
> UPDATE. Does anyone know the reason for this? A useful 
> application would be
> to indicate a changed asserted identity when a change of 
> party occurs in a
> legacy network (e.g., due to transfer). If not allowed in UPDATE, a
> re-INVITE would need to be used, but this introduces an extra message.
> 
> John Elwell ([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

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 7 May 2003 19:10:39 +0100

I believe the thinking when the document was developed was essentially to allow it in methods that either initiated a dialog, or were sent outside of a dialog. There was therefore no intent to cover reINVITE at that time, although I do not think it was explicitly excluded in the RFC. I am not sure how the BYE got added in respect of this, maybe someone else can clarify. The NOTIFY is there in respect of a NOTIFY that confirms a SUBSCRIBE dialog.

This would allow the exchange of identities between the end users under these circumstances.

From what you are indicating, it looks like you would want to extend the above to cover target refresh requests.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> Sent: 07 May 2003 10:20

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 May 2003 10:34:04 +0100

Jonathan,

Thanks for your input. I too would prefer 2.

John

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 19 May 2003 09:03
> To: Elwell, John
> Cc: 'Rohan Mahy'; 'Drage, Keith (Keith)'; [email-masked]'
> Subject: Re: [Sip] UPDATE and P-Asserted-ID
> 
> 
> I agree that Contact is not the right place to identify the user. 
> Rather, it is a form of identification for a device.
> 
> There is really a bigger issue here, which is the scope of the 
> information that can be updated by a target refresh request (of which 
> UPDATE is one). RFC 3261 refers only to specific pieces of the state 
> of a dialog which can be updated (cseq, contact headers). There are 
> other pieces of state held for the lifetime of the dialog, 
> such as the 
>   UA capabilities (from the Supported header field), methods allowed 
> (Allow header field), and so on. Can these be updated by a target 
> refresh request?
> 
> RFC 3261 is silent on this point, and I think the question is similar 
> to whether an implementation would even update the P-Asserted-ID 
> header field in a re-INVITE (forgetting UPDATE even).
> 
> Our thinking was really that this information was static, and 
> therefore would be set by the initial INVITE and not changed 
> afterwards, although the spec never explicitly states this. The issue 
> here is that folks believe P-Asserted-ID is NOT static (i.e., because 
> of a call transfer), and therefore would need to change. I believe 
> there are actually a few cases where it would change, such as various 
> 3pcc cases too.
> 
> So, considering the general problem, there are a few solutions:
> 
> 1. Each header field that conveys dialog-associated state would 
> indicate whether or not that state is updated by a target 
> refresh request.
> 
> 2. We specify a blanket rule for all such headers that their state is 
> updated by a target refresh request (absence of a header would imply 
> no update).
> 
> 3. We specify a blanket rule for all such headers that their state is 
> never updated by a target refresh request.
> 
> 4. We specify a default rule for all such headers, but allow 
> individual headers to override it.
> 
> 
> In the interests of simplicity I would tend to lean towards (2). The 
> best place for this, of course, is rfc 3261, in which case we should 
> treat this as a bug against the spec.
> 
> -Jonathan R.
> 
> 
> Elwell, John wrote:
> > Rohan,
> > 
> > The qsig2sip draft is silent on the subject of the contact 
> header. So too is
> > the ISUP-SIP draft (except on the subject of contact headers in 3xx
> > response). It is not clear to me that a contact header 
> should necessarily
> > reflect the identity of the remote party in the legacy 
> network. Therefore
> > there may be no need to change the contact header when 
> transfer occurs in
> > the legacy network.
> > 
> > Consider the following case. An INVITE request leaves the 
> SIP network at an
> > egress gateway to QSIG. The gateway receives a QSIG 
> ALERTING message and
> > sends back a 180 response containing a contact header. It 
> would be possible
> > for this contact header to reflect the identity of the 
> party to whom the
> > QSIG SETUP message was directed or, except where prevented 
> by privacy, the
> > identity of the party actually being alerted (can be 
> different because of
> > forwarding). Now, suppose after alerting but before answer 
> the call is
> > forwarded, so that the party who answers is not the party 
> identified in the
> > contact header in the 180 response. What should go in the 
> contact header of
> > the 200 response: the same value that was in the 180 
> contact header; or a
> > different value reflecting the identity of the answering 
> party? It is not
> > clear to me whether the contact header is allowed to or 
> should change in
> > this situation.
> > 
> > Because if is not always feasible, because of privacy, 
> forwarding etc. for
> > the contact header issued by a gateway always to reflect 
> the identity of the
> > remote party in the legacy network, I see the contact 
> header primarily as a
> > means of identifying the gateway, rather than the remote 
> party. That is why
> > the qsig2sip draft is silent on this issue - the choice of 
> contact header is
> > an implementation matter for the gateway.
> > 
> > Regards,
> > 
> > John
> > 
> > 
> >>From: Rohan Mahy [mailto:[email-masked]]
> >>Sent: 13 May 2003 00:12
> >>To: Elwell, John
> >>Cc: 'Drage, Keith (Keith)'; [email-masked]'
> >>Subject: Re: [Sip] UPDATE and P-Asserted-ID
> >>
> >>
> >>John,
> >>
> >>I believe you still should generate a new Contact header, 
> even if you 
> >>are only changing the display name.
> >>
> >>thanks,
> >>-rohan
> >>
> >>On Thursday, May 8, 2003, at 01:21 AM, Elwell, John wrote:
> >>
> >>
> >>>Keith,
> >>>
> >>>Thanks for your response. However, I do not wish to cover target 
> >>>refresh. As
> >>>I understand from section 12 of RFC3261, local and remote 
> >>
> >>targets are
> >>
> >>>derived from Contact headers. The scenario I have in mind is where 
> >>>something
> >>>happens behind a gateway. However, the gateway remains the same and
> >>>therefore it does not need to generate a new Contact header.
> >>>
> >>>John ([email-masked])
> >>>
> >>>
> >>>>From: Drage, Keith (Keith) [mailto:[email-masked]]
> >>>>Sent: 07 May 2003 19:11
> >>>>To: Elwell, John; [email-masked]'
> >>>>Subject: RE: [Sip] UPDATE and P-Asserted-ID
> >>>>
> >>>>
> >>>>I believe the thinking when the document was developed was
> >>>>essentially to allow it in methods that either initiated a
> >>>>dialog, or were sent outside of a dialog. There was therefore
> >>>>no intent to cover reINVITE at that time, although I do not
> >>>>think it was explicitly excluded in the RFC. I am not sure
> >>>>how the BYE got added in respect of this, maybe someone else
> >>>>can clarify. The NOTIFY is there in respect of a NOTIFY that
> >>>>confirms a SUBSCRIBE dialog.
> >>>>
> >>>>From what you are indicating, it looks like you would want to
> >>>>extend the above to cover target refresh requests.
> >>>>
> >>>>Keith
> >>>>
> >>>>Keith Drage
> >>>>Lucent Technologies
> >>>>Tel: +44 1793 776249
> >>>>Email: [email-masked]
> >>>>
> >>>>
> >>>>>legacy network (e.g., due to transfer). If not allowed in 
> >>
> >>UPDATE, a
> >>
> >>>>>re-INVITE would need to be used, but this introduces an
> >>>>
> >>>>extra message.
> >>>>
> >>>>>Use [email-masked] for new developments on the 
> >>
> >>application of sip
> >>
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Scientist                             Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>

---

From: [email-masked]
Date: Mon, 19 May 2003 14:45:31 +0300

Option 2 is ok for me, but we have to soften the SHOULD requirement to add contact headers in requests within dialog (section 12.2) and that it SHOULD contain the same value as the previous request within dialog.

Regards,
Hisham

> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, May 19, 2003 11:03 AM
> To: Elwell, John

---

From: "Hearty, John" <[email-masked]>
Date: Mon, 19 May 2003 08:57:13 -0600

I'd be interested in seeing all "such headers" listed, and consider security implications carefully before covering them with a blanket rule.

> Sent: Monday, May 19, 2003 2:03 AM
> To: Elwell, John

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 23 May 2003 11:21:26 +0100

Jonathan's approach seems reasonable, and since P-Asserted-Id just
represents the identity of the originator of the *message* we could expect
it to change during a dialog - I suppose there is a philosphical question
that if the identity of the SIP UAS changes, does that mean it is now a
logically different UAS and so a new dialog should be established ? even if
it's the same physical device so that all the state needed to maintain a
single dialog is still available ?? I guess this is the case when call
forward/transfer happens downstream of a SIP->X gateway.

Equally, were a device to de-register and re-register with a new Address Of
Record, does this represent an 'identity change' for that UA ? Could it
meaningfully update its identity in any ongoing dialogs ?

I think there should be scope for individual headers to specify that their
state cannot be updated mid-dialog. Not having looked through all the 'such
headers' referred to by Jonathan (not even knowing what this list is!) we
can't rule out that the meaning of a mid-dialog update for one of these
might not be well-defined i.e. it has no sensible meaning or is ambiguous.
In those cases we would need to rule out mid-dialog updates, or define the
meaning of them for that header.

...Mark

> From: Michael Thomas [mailto:[email-masked]]
> Sent: 19 May 2003 21:18
> To: Jonathan Rosenberg
> Cc: Elwell, John; 'Rohan Mahy'; 'Drage, Keith (Keith)'; [email-masked]'
> Jonathan Rosenberg writes:
> This seems quite reasonable to me as well --
> special casing "initial" from subsequent dialog
> seems pretty fraught. The only reason that I can
> think of why you might want to do that is when the
> state assembly/teardown of a mid-session change
> was so onerous and/or ambiguous to other state
> that it was prudent to set up the state once and
> leave it be. It doesn't seem to me that that's the
> case here, but I'm hardly an expert.
> 
> 	 Mike