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

From: "Elwell, John" <[email-masked]>
Date: Tue, 13 May 2003 14:23:57 +0100

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

> -----Original Message-----
> 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])
> >
> >> -----Original Message-----
> >> 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.
> >>
> >> 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]
> >>
> >>> -----Original Message-----
> >>> From: Elwell, John [mailto:[email-masked]]
> >>> Sent: 07 May 2003 10:20
> >>> 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
> 
_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 May 2003 04:03:07 -0400

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.

-- 
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: Michael Thomas <[email-masked]>
Date: Mon, 19 May 2003 13:17:49 -0700 (PDT)

> treat this as a bug against the spec.

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