I'll answer part of your long questionnaire ;-)
At 02:14 PM 11/21/2007, Dean Willis wrote:
Now for the questions:
1) RFC 4412 (which defines RPH) is not clear to me on the
relationship between priorities, requests, responses, and dialogs.
RFC 4412 explicitly creates a priority for requests and dialogs
within UAs and Proxies that allow a priority to be assigned within a
namespace. I agree it isn't so clear about responses; though it has
text stated proxies should be wary of changing priorities within a
response by "colluding UAs."
In stateful proxies, responses were supposed to be afforded the same
priority as their request partner message within a transaction. This
is to give all messages within a transaction a priority for special
handling in processing queues, and rejections if a proxy knew a lower
priority request wouldn't get through to the destination (perhaps
because it knew the UAS was already engaged in a higher priority dialog).
RFC 4412 was not clear what to do with responses in stateless
proxies. This is what draft-polk- sip-rph-in-responses-00 currently addresses.
Specifically, does an RPH value expressed in an INVITE transaction
apply to a dialog, or does it apply only to the request in which it
appears?
see above (it applies to everything (requests and dialogs) except for
in responses in stateless proxies)
This has implications for what happens should an RPH value
change mid-dialog,
obviously the transaction occurs before dialog changes, so the dialog
would maintain the priority it currently has until successful
acceptance of the new transaction about the dialog changes the
priority of the dialog.
which is what the rph-responses work is proposing.
...which draft-polk- sip-rph-in-responses-00 currently is not yet
The only way I can see that this works is for RPH values to apply
only to the request (or perhaps request or response) in which they
occur.
see my reply, and I think this works everywhere the namespace is
accepted. In other words, RPH applies to a transaction involving
stateful proxies until the dialog starts, which takes on that
priority within the dialog. If a new transaction occurs within that
Call-ID, the new priority affects that transaction until it is
successful, then the dialog takes on that new priority.
Supporting UAs would then have to remember the RPH value
of course they would, per dialog
and
include it in all further requests (and perhaps responses).
yes, unless the request includes a change in priorities within an
acceptable namespace
If the
RPH value is not resent, then the RPH value would cease to apply.
This isn't stated, but I think once a priority is established within
a dialog, it doesn't cease because a new transaction within that
dialog didn't contain the same namespace.priority-value. But I do
expect any new transaction to contain at least the same RPH values as
the existing dialog.
Now
here's the problem: The RPH value seems to impact the processing of
the SIP messages themselves, and the priority of the media flow
established in a dialog.
This isn't a problem, since this is the intent
So what happens to the priority of a media flow when subsequent
transactions within the dialog experience changes in RPH values?
The priority of the media flow changes to match that of the new
transaction within the established dialog.
If the media established a priority in the first place, it shouldn't
be hard to change the priority mid-stream, should it?
If this changes the DSCP value, then there needs to be a mechanism to
change the DSCP. I didn't rev this ID for this meeting, but I will
very soon (taking out all mention of servers from the ID to satisfy
resistance I got within the MMUSIC WG in Chicago)
http://www.ietf.org/internet-drafts/draft-polk-mmusic-dscp-attribute-01.txt
_______________________________________________
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
