Subject: Re: [Tsvwg] Paradox in draft-baker-tsvwg-mlpp-that-works-01

From: [email-masked]
Date: Thu, 25 Mar 2004 11:20:16 EST

In a message dated 3/24/2004 12:45:40 PM Eastern Standard Time, 
[email-masked] writes:

> No, I'm not. I can have those 50 phones be SIP based without any server - 
> meaning each phone signals its own set-up across that T1 to a phone on the 
> other LAN.
> 
> In this scenario, how is the application layer of any device supposed to 
> know the admission control parameters of the T1 and any other capacity 
> constraints?
> 
> 

That is why, until someone comes up with a good answer to that problem, any 
real network concerned with QOS and congestion will require that call setup be 
controlled by a proxy server that does application layer things like knowing 
something about admission control parameters, especially when multiple 
precedence levels are required.

I personally doubt that a really workable solution will ever be devised to 
allow individual User Agents (IP phones) to perform admission control of call 
setup without a server, but then, I won't pre-judge the intelligence and 
ingenuity of the assembled experts in the IETF. This is a real challenge to come up 
with a solution.

Mike Pierce

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 25 Mar 2004 13:10:07 -0600

Mike

comment in-line

At 11:20 AM 3/25/2004 -0500, [email-masked] wrote:
>That is why, until someone comes up with a good answer to that problem, 
>any real network concerned with QOS and congestion will require that call 
>setup be controlled by a proxy server that does application layer things 
>like knowing something about admission control parameters, especially when 
>multiple precedence levels are required.
>
>allow individual User Agents (IP phones) to perform admission control of 
>call setup without a server

It's not so much that the UAs are doing this instead of a Proxy, it is as 
in RFC3312, the UAs are syncing with the Proxies Directing your attention 
to the call flow on page 6 of that RFC to see RSVP signalled by the UA, and 
it an error occurs, the UA informs the Proxy that RSVP failed. The UA or 
Proxy can decide to continue with the call set-up based on local policy of 
that domain.

>, but then, I won't pre-judge the intelligence and ingenuity of the 
>assembled experts in the IETF. This is a real challenge to come up with a 
>solution.
>
>Mike Pierce

cheers,
James

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

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