Subject: [Sip] Poll -- expert review of draft-garcia-sip-called-party-id

From: "Dean Willis" <[email-masked]>
Date: Thu, 23 May 2002 18:25:01 -0500

So team, what's the conclusion, if any, on
draft-garcia-sip-called-party-id?

Do we have a consensus for, consensus against, or require further
consideration?

--
Dean

_______________________________________________
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: "Cullen Jennings" <[email-masked]>
Date: Fri, 24 May 2002 00:13:16 -0700

I see this draft as dealing with the issue of a proxy retargeting
sip:[email-masked] to sip:[email-masked]

As a proposed change, how would you feel about changing the syntax from
P-Called-Party-ID to something like

P-History: sip:[email-masked]
or
P-History:
sip:[email-masked];reason=SIP;cause=302;text="registrar
retargeted"

I understand that 3G wishes to resolve this by June, however, I think that
if we wanted to, we could do a P-History just as fast as a
P-Called-Party-ID. The existence of a non compatible Called-Party will
complicate getting History done. If the consensus is not to ever do History,
people should express on the sipping list that the requirements are bogus.

Cullen

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 24 May 2002 11:23:09 +0300

Cullen:

We are moving into dangerous grounds, because you want to solve the
history issue. The aim of this header is much more narrower in scope.
We don't want to solve the history problem. We just want to send an
indication to the UAS with one out of many identities that the INVITE
was sent.

You claim that a non compatible Called-Party will complicate getting 
history done, and I disagree with this point.

In the first proposal you make, the P-History would look like:

which is exactly the same as:

P-Called-Party-ID: sip:[email-masked]

with the exception that the P-Called-Party-ID contains the semantics
of the header, why P-History is broader and we need to include something
else to give a hint to the UAS.

I suspect that is the reason why you have your second proposal, which is:

P-History:

And this is the problem to me. We would need to define the reason, 
cause, text, etc, for all the situations where a proxy retargets a
URI. Isn't this the whole History header that still is requirements
phase?

I don't see any incompatibility problem if we have a P-Called-Party-ID
with a clear and simple semantics, at the same time that we work 
towards a broad History, that has to include the requirements of a
P-Called-Party-ID, and will eventually take over the P-Called-Party-ID.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002