Subject: Re: [MMUSIC] MMUSIC agenda posted

From: Colin Perkins <[email-masked]>
Date: Sun, 5 Nov 2006 12:01:23 -0800

On 25 Oct 2006, at 02:47, Joerg Ott wrote:
> The revised MMUSIC is now available at:
> http://www3.ietf.org/proceedings/06nov/agenda/mmusic.txt

If you're presenting, please ensure the chairs get your slides ahead  
of time. Plain white background, minimal logos and animation, PDF  
(preferred) or PowerPoint format.

Colin

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 6 Nov 2006 07:01:07 -0800

Yes - sorry for the typo.
Colin

On 5 Nov 2006, at 19:22, Philip Matthews wrote:
> Shouldn't the agenda refer to ICE-TCP-02?
>
> - Philip
>
>
> On 5-Nov-06, at 15:01 , Colin Perkins wrote:
>
>> If you're presenting, please ensure the chairs get your slides  
>> ahead of time. Plain white background, minimal logos and  
>> animation, PDF (preferred) or PowerPoint format.
>>
>> Colin
>>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 6 Nov 2006 12:42:13 -0500

Hello,

In general this is a very nice draft. There are many ways to solve this
problem but none on a per call basis that leverages so much real
installed networks. VoIP networks today use B2BUAs and SBCs heavily
(whether people like it or not) and having them able to convey dscp
markings to end nodes simplifies operational considerably. Today these
devices already look at codecs, bandwidth attribute, and others to
provide cac, mark packets, normalize (avoid) transcoding, etc. 

Based on my comments it is clear I do not belive a SIP endpoint in a
different domain (or AS) would be able or allowed to tell its peer the
dscp it should use in packets. But I do not think it diminishes the
applicability of the draft since B2BUAs and variants are heavily used in
the access edge or border. 

On my wish list would be a way for the endpoint or intermediary to be
able to convey a string that would denote a "class" as well. Of course
this does not avoid the problem of enforcing (maybe nothing can), where
we need to make sure that endpoint A is marking packets with correct
endpoint XY. But I would assume in a trusted environment this wouldn't
be severe.

Thanks,

REinaldo