Subject: RE: [NSIS] QSPEC Issue: Inclusion of H.460.4/H.323 Priority Parameters

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Wed, 14 Sep 2005 15:27:00 -0400

API is only the half-baked solution if all entities are located
physically at the same place.

If the entities are located at different geographical locations, a
protocol is needed.

In any situation (API or protocol), the original problem remains the
same as follows as mentioned in the earlier email:

1. SIP is an application/call layer signaling protocol that will express
priority at the application/call level. It can differentiate between
different call types. In turn, it may, but not always, translate the
priority to RTP media of one call versus other ones.

2. The question is this: How can a call layer priority be mapped to that
of the IP layer packets? 

Mapping problems of priority levels between media of different media of
different call priorities need to be addressed to be more precise.

Thanks,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2005 3:12 PM
To: Roy, Radhika (AEAD); [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: RE: [NSIS] QSPEC Issue: Inclusion of H.460.4/H.323 Priority
Parameters

At 02:55 PM 9/14/2005 -0400, Roy, Radhika \(AEAD\) wrote:
>2. The question is this: How can a call layer priority be mapped to
that
>of the IP layer packets?

an API

>Thanks,
>Radhika

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

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

---

From: David R Oran <[email-masked]>
Date: Wed, 14 Sep 2005 18:44:44 -0400

> If the entities are located at different geographical locations, a
Right, and we have two, RSVP and NSIS. The idea that we invent  
another one just to carry priority/preemption information is, excuse  
the bluntness, nuts.

> priority to RTP media of one call versus other ones.
No, it ALWAYS has to do this. The semantics of signaling and data  
transport are different. You can't derive one from the other. In  
fact, a call with high priority for audio might not necessarily have  
high priority for video - the video may be a "nice to have".  
Conversely, if I'm doing surveillance the video might be essential  
but the audio could be dropped without fundamental loss of capability.

> 2. The question is this: How can a call layer priority be mapped to  
Yes, and that is application specific, not protocol specific. These  
protocols are used for multiple applications. Building the mapping  
into the protocols or the standards is fundamentally the wrong thing  
to do.

> different call priorities need to be addressed to be more precise.
I disagree. Sorry if I cant' sugar-coat this...

Cheers, Dave.