I think we'll also need a new response code: 4xx I'm confused, too many
URIs in request
Seriously, a solution based on yet another header with an URI IMHO
introduces more complexity/confusion than solving the issue is worth.
Better to limit the scope of the problem we're trying to solve and
document the known limitations / use cases. If the problem is to deliver
the request URI to a UAS which is registered with its home proxy, and
there is a mechanism by which the proxy can detect support by the UAS,
Jonathan's solution is fine. To other proxies being in the path not
supporting this mechanism it would still appear as basic loose routing,
so I don't see the issue there (if needed we could extend the Path
mechanism with some flag as done for outbound)
Regards,
Jeroen
Francois Audet wrote:
I think we should charge customers per URI in the protocol.
We'd be rich.
-----Original Message-----
From: Elwell, John [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 15, 2008 01:20
To: Christer Holmberg; Audet, Francois (SC100:3055)
Cc: [email protected]; DRAGE, Keith (Keith); Paul Kyzivat
Subject: RE: [Sip] RE: Delivering request-URI and parameters
to UAS via proxy
Christer,
I guess what still confuses me is, when both Target and P-CPI
are used, which comes first, i.e., which represents the
earlier target? When I read the draft, I thought Target was
earlier. From various clarifying emails I now get the
impression that Target is later. Can you confirm?
Picking up on Francois' point about History-Info, with the
introduction of Target and P-CPI we do indeed have a lot of
URIs, and of course History-Info can already convey all these
URIs and any others. The difference is that History-Info does
not give particular semantics to each of the URIs it conveys
- they are simply a succession of targets.
With Target and P-CPI we are aiming to define specific
semantics. I am concerned whether we will be able to define
these semantics tightly enough to ensure consistent
implementations. The more URIs we try to define, the harder
it will be to assign each one a clearly distinguishable
meaning. I hope the next draft will help.
John
-----Original Message-----
From: Christer Holmberg [mailto:[EMAIL PROTECTED]
Sent: 15 January 2008 08:48
To: Francois Audet
Cc: [email protected]; DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John
Subject: RE: [Sip] RE: Delivering request-URI and parameters to UAS
via proxy
Hi,
P-CPI could probably be useful in some cases, in addition to Loose
Route/Target. And, as the draft says, P-CPI will still have
to be used
in IMS, because there are procedures defined for it.
However, again, the purpose of the draft was to provide an
alternative
to the Loose Route alternative, and that alternative is Target only.
I am working on an updated version of the draft to make that more
clear.
Regards,
Christer
Hum. I guess then P-Called-ID would then be useful with
Loose-route
as well (although now I'm thinking that History-Info covers it).
I think explaining all that in great and precise details, with a
concrete example would be very useful.
And then we could compare P-Target with Loose-route.
-----Original Message-----
From: Christer Holmberg [mailto:[EMAIL PROTECTED]
Sent: Monday, January 14, 2008 03:56
To: Audet, Francois (SC100:3055)
Cc: [email protected]; DRAGE, Keith (Keith); Paul Kyzivat;
Elwell, John
Subject: RE: [Sip] RE: Delivering request-URI and
parameters to UAS
via proxy
Hi Francois,
I think what you meant by Target was more the "Current"
target as opposed to the Initiatl Target.
Yes.
And if that's the case, then I don't see why it is
different from
P-Called-ID (although I might be missing something
with what the
P-Called_ID is supposed to be).
In the draft we try to explain the difference. But, we are
working on
the text to make it more clear.
The P-CPI is inserted when the R-URI is rewritten by
the Contact
address of the UAS. RFC3455 calls that operation
"retargeting", but we
don't think that is the definition for retarget used in the
ua-loose-route draft, which says:
"When a home proxy receives a request and accesses a
location service,
the resulting contact(s) obtained from the location service are
considered the last hop in the route towards the entity
addressed by
the Request-URI. Since that target, almost by definition,
can claim
the identity of the URI prior to translation, the operation
is one of
routing and not retargeting."
So, if we follow the definitions in the ua-loose-route
draft, P-CPI
would be inserted due to a reroute - not retarget.
But, no matter whether we call it retarget or reroute,
the point is
that the P-CPI is inserted when the R-URI is rewritten with the
Contact address of the UAS. The scope of Target is wider
than that,
and can be used in any retargeting situation.
Regards,
Christer
_______________________________________________
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
