Subject: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer

From: ken carlberg <[email-masked]>
Date: Thu, 2 Nov 2006 13:15:29 -0500

James,

I'm curious as to the case of multicast streams and the conference  
model.  your examples focus on the unicast model, and yet in the land  
mobile radio case (where folks are pushing IP into), there are cases  
where some sender(s) have a higher precedence than the other group  
members -- an example being a fire battalion chief having higher  
precedence than other fireman/first-responders.

I'm not sure how your draft satisfies this group model.

-ken

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 2 Nov 2006 14:13:20 -0800

> an example being a fire battalion chief having higher  
> precedence than other fireman/first-responders

This is correctly dealt with IMHO at the application layer (SIP), not in
the IP layers and not based on QoS, since there is no QoS e2e [and for
good reasons :-)]

See
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-00.txt  

and also

http://www1.ietf.org/mail-archive/web/tsvwg/current/msg06510.html 

Henry

-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: Thursday, November 02, 2006 12:15 PM
To: [email-masked]
Subject: [MMUSIC] New ID on conveying a DSCP marking/remarking in an
Offer

James,

-ken

---

From: ken carlberg <[email-masked]>
Date: Thu, 2 Nov 2006 22:32:50 -0500

Henry,

I realize there are ways to address the example I brought up, but the  
question still remains concerning the impact of James's proposal in  
conveying DSCP markings via SDP.  If the answer is "don't do this  
with multicast/conference state", then that should be stated.  Or if  
James has a different insight, it would be helpful to state this in  
the text.  It just didn't seem clear to me how asymmetric DSCPs could  
be applied in the group context under this proposed draft.

regards,

-ken

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 3 Nov 2006 04:47:13 -0800

Ken,

Adding QoS to SDP offer/answer and to the respective SIP signaling would
require some work or coordination with SIPPING as well and possibly with
other application level folks. That's all I meant to say.

Henry

-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: Thursday, November 02, 2006 9:33 PM
To: Henry Sinnreich
Cc: [email-masked]
Subject: Re: [MMUSIC] New ID on conveying a DSCP marking/remarking in an
Offer

Henry,

regards,

-ken

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 03 Nov 2006 12:54:02 -0600

>Ken,

Ken - I'm open to suggestions how and in what circumstances there needs to 
be text accounting for asynchronous DSCP marking of an RTP stream.

>other application level folks.

Henry - I certainly didn't/don't intend for this to be done in any one WG 
vaccuum.  I also do not expect this mechanism/extension to work in all 
environments.

That said, there are some large intra-networks that can control the local 
policy of the devices within that intra-network to take advantage of this 
mehcanism - even if the destination is outside that 
intra-network.  Consider this to be enabling a PDB, where the D in PDB is 
the intra-network.  Nothing is preventing an adjacent network from using 
this mechanism too, or even taking a hint from the neighbor network (worked 
out by an SLA of course), but it's failure to do so doesn't adversely 
affect the original network using this mechanism.

>That's all I meant to say.
>
>Henry
>