Christer,
My concern with P-Called-Party-ID is similar to my concern on
History-Info. On History-Info, the draft states:
Firstly, it would cause the Request-URI to be relegated to nothing
more than an indicator of the next hop for the request, identical
exactly to the purpose of the Route header field. This results in
two things in the SIP specification which do exactly the same thing.
Worse still, this is not just for some small feature of SIP (where
such duplication might not be a big deal), but rather, it would be a
duplication of SIP's primary function - routing of a call towards a
target.
This concern applies exactly to P-Called-Party-ID. Indeed, its even
worse, since now we would have, in a request:
Request-URI
To
P-Called-Party-ID
History-Info
Route
and I challenge you to explain to implementors what the differences are.
What would happen when they are inconsistent?
My objective was to reduce this count. Indeed I was hopeful that
UA-loose-route would allow us to deprecate P-Called-Party-ID, not the
other way around. WIth UA-loose-route, we end up with:
Request-URI: identifies the target
Route: tells you how to get to the target
To: tells you the original target
History info: sequence of identities of targets
which is much cleaner.
So, functionally, P-Called-Party-ID could work. Any number of things
*can* work.
-Jonathan R.
Christer Holmberg (JO/LMF) wrote:
Hi,
It is entirely appropriate at this stage to put forward
alternatives. It is even more appropriate to do it now rather than
in 6 months time.
However please do not expect the editor to elaborate them. If the
WG has ideas, send text, either by individual author drafts, or by
the mailing list.
Regarding the P-Called-Party header, there already IS an RFC
describing the header, and what it is used for. So, IF it already
solves the problem (RFC3455 does say that the header is used to
convey the AOR to the UAS), why would we need a separate draft? The
only additional information that a draft could contain are the
use-cases where receiving the AOR is important - but those use-cases
are solution independent and already described in Jonathan's draft.
Of course, if we want to define a NEW header, or a NEW URI parameter,
that may be done in a separate draft.
But, no matter how we do it, I think the author should at least
indicate whether he has already thought about the alternatives that
have been presented, and why he thinks that they don't work.
Regards,
Christer
-----Original Message----- From: Christer Holmberg (JO/LMF)
[mailto:[EMAIL PROTECTED] Sent: Thursday, June 14,
2007 10:51 AM To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF
SIP List Subject: RE: [Sip] UA Loose Routing
Hi Keith,
The text you sent says:
"Consensus noted that we do need some sort of solution for
the general
problem of delivery of URI parameters across contact-routing
operations."
I have no problems with that.
I also have no problem with using Jonathan's draft as base line,
because the draft discusses the problem in a good way.
But, still: as the text says, the agreement was to come up
with SOME
SORT OF SOLUTION, which to me does not mean that we have agreed
to adopt the specific solution in Jonathan's draft. We should
also be "allowed" to discuss alternative solutions, whether they
are based on
P-Called-Party, some other header, some URI parameter, or
whatever...
Maybe those alternative solutions do not work, and then we should
describe that (as Jonathan has done for the To header- and
History header alternatives).
Regards,
Christer
-----Original Message----- From: DRAGE, Keith (Keith)
[mailto:[EMAIL PROTECTED] Sent: 14. kesäkuuta 2007
12:40 To: Christer Holmberg (JO/LMF); Jonathan Rosenberg; IETF
SIP List Subject: RE: [Sip] UA Loose Routing
You appear to be questioning whether the solution was
adopted. The
minutes state:
-------------------------------------------------------------------
Topic: GRUU and Supporting Drafts Led by Jonathan Rosenberg
Slides included in proceedings Read:
draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00
Change since last version reviewed.
Issue: GRUU subtype names. The room demonstrated a slight
preference
for the names used in -11 over known alternatives, but
nobody seems
particularly enamored with these names and the floor
remains open to
suggestions.
Discussion on ua-loose-route draft deferred to next session.
Session 2: Friday 0900-1130 Grand Ballroom C
Topic: UA-loose-route, continued from previous session.
Consensus noted that we do need some sort of solution for
the general
problem of delivery of URI parameters across contact-routing
operations.
Issue: Concerns raised about backward compatibility. Noted that
compliant P-CSCF should be OK. Suggested that we have a
design team
revisit call-flows and analyze for backward compatibility
issues.
Issue: Does GRUU normatively depend on this work? Resolved:
GRUU does not reference this document. However, some
participants feel
it should, as the benefit of GRUU cannot be fully
recognized in the
absence of this specification. The chairs asked for a
hum, and the
consensus of the room is that GRUU and ua-loose-route can
proceed independently.
Question: Adopt this draft as baseline text for a WG
effort, should
the ADs approve the milestone? Consensus to adopt noted by
chairs. To-do: Chairs to work with AD to set new milestone.
----------------------------------------------------------------------
The minutes quite clearly say "Adopt this draft as baseline
text for a
WG effort" and given that the charter item now exists, then
I believe
that we are entitled to call for the editor (Jonathan) to
submit the
current text as draft-ietf-sip-ua-loose-route.
I agree the file name says loose-route, but I don'y think
we should
change that. After all, we lose that filename when it gets
published
as an RFC anyway.
The charter item states
Dec 2007 Delivering request-URI and parameters to UAS via
proxy to WGLC Feb 2008 Delivering request-URI and parameters
to UAS via proxy to IESG (PS)
I assume that you are OK with this.
What I would suggest is that you address specific comments to
the title of the deliverable:
Applying Loose Routing to Session Initiation Protocol (SIP)
User Agents (UA)
And to the abstract:
Abstract
A key part of the behavior of the Session Initiation
Protocol (SIP)
is that SIP proxies rewrite the Request-URI as a request moves
throughout the network. Over the years, experience has
shown this
to be problematic. It makes it difficult to use Request URI
for service invocation, complicates emergency services, makes
it
more complex
to support aliases, and so on. Architecturally, it confounds
the concepts of address and route. This document proposes
to change
this through a new mechanism called UA loose routing.
As you think appropriate to your concerns.
Alternatively, if you (or indeed any other SIP WG member)
do have a
completely different solution, then there is still time
to post an
individual draft or post a skeleton of a mechanism to the list.
Regards
Keith
-----Original Message----- From: Christer Holmberg (JO/LMF)
[mailto:[EMAIL PROTECTED] Sent: Wednesday, June
13, 2007 8:52 PM To: DRAGE, Keith (Keith); Jonathan
Rosenberg; IETF SIP List Subject: RE: [Sip] UA Loose Routing
Hi,
We can call it loose route if we want, but I think the
initial focus
should be the problem we are going to solve (I don't think
we agreed
on a specific solution at #67), and we should look into
alternative
solutions (the draft does that in some extent, but
other possible
alternatives have also been mentioned).
Or, do you prefer to have separate drafts describing
alternative
solutions for the problem?
Regards,
Christer
-----Original Message----- From: DRAGE, Keith (Keith)
[mailto:[EMAIL PROTECTED] Sent: 13. kesäkuuta 2007
22:25 To: Jonathan Rosenberg; IETF SIP List Subject: RE:
[Sip] UA Loose Routing
(As WG chair)
As well as agreeing to charter the item, we actually agreed
at IETF#67
that this draft was a suitable candidate to fulfil that
charter item.
Therefore unless issues are raised with this, I would
request the
editor (as Jonathan is editor) to submit the next
version of this
document as draft-ietf-sip-ua-loose-route-00.
Regards
Keith
-----Original Message----- From: Jonathan Rosenberg
[mailto:[EMAIL PROTECTED] Sent: Wednesday, June 13, 2007
4:02 AM To: IETF SIP List Subject: [Sip] UA Loose Routing
Issue #1: Backwards
compatibility
I've recently revised my draft on UA loose routing. You
can
pick it up
here:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo
se-route-01.txt
This draft is meant to fulfill one of our charter items:
Feb 2008 Delivering request-URI and parameters to UAS
via proxy to IESG (PS)
As folks may recall, the GRUU spec used to have these
things called
grids, which allowed a UA to add its own parameters to
the
GRUU before
handing it out. Several GRUU revisions back, this
function
got yanked
because it was recognized that the problem was more
general
than GRUU,
and would be useful for AOR as well.
Two IETFs back I presented this draft briefly during a
SIP session.
There was a lot of interest and people liked it
architecturally,
however there were two open issues that needed to get
resolved. This
mail is meant to start discussion on one of them -
backwards
compatibility.
THe mechanism basically changes the way proxies handle
requests.
Instead of rewriting the request URI for out-of-dialog
requests,
they'll push a route header and leave the r-uri alone.
This
allows the
original R-URI and any parameters it contains to get
delivered to the
UAS.
So, the main issue is, what kinds of backwards
compatibility problems
will this cause. The draft provides a basic mechanism
whereby a UA
includes an option tag in the REGISTER, and the registrar
indicates
that it is using this mechanism or not. So we can
negotiate this
between a UA and registrar easily. Now, the problem is
with intermediate proxies. If there is an edge proxy
between the
UA and its
registrar, it will now see requests targeted to the UA,
which contain
a Route header beyond itself, even though it thinks its
the
edge proxy
and the last point of contact before the UA. Technically,
if this edge
proxy is compliant to rfc3261 it would work. However, the
question is
whether proxies in the wild would properly work in
this case.
If folks can comment based on their own products, or
their experiences, on whether they think this would work,
or
concerns they
have, that would be great. THere are solutions that would
allow us to
disable the mechanism when intermediate proxies don't
support it, but
they are more complex and I'd rather avoid it.
THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D.
600
Lanidex Plaza
Cisco Fellow
Parsippany, NJ
07054-2711 Cisco Systems [EMAIL PROTECTED]
FAX:
(973) 952-5050
http://www.jdrosen.net PHONE:
(973) 952-5000
http://www.cisco.com
_______________________________________________ Sip
mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP
Protocol Use
[EMAIL PROTECTED] for questions on
current sip Use
[EMAIL PROTECTED] 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 PROTECTED] for questions on
current sip Use
[EMAIL PROTECTED] for new developments on the
application of sip
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Cisco Fellow Parsippany, NJ 07054-2711
Cisco Systems
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
