Subject: RE: [Ieprep] deja vu

From: "James M. Polk" <[email-masked]>
Date: Fri, 21 Nov 2003 16:32:02 -0600

At 03:52 PM 11/21/2003 -0600, Ayyasamy, Senthilkumar  \(UMKC-Student\) wrote:
> >>One underlying assumption you are making about the CAC
> >>function below is
> >>that each knows where a destination endpoint is.
> >>You are not accounting for
> >>the mobility IP inherently brings to future networks.
>
>kimberly's proposal is the easiest solution using existing
>standards (RSVP + some kind of marking + EF).

We wouldn't be having this disagreement if this was Kimberly's proposal. 
She isn't proposing RSVP at all - because it would be *the CAC function*; 
thereby not requiring any IP PBX to count the number of calls that exist on 
an outbound trunk from a LAN.

>  It is far
>better than creating a new PHB (which doesn't actually
>implement MLPP feature.i.e. preemption.)

At least the two of us agree, this will not solve the problem

>As you mention,
>she did not take receiver end network profile into account
>(which requires COPS etc.) But, Is it a necessary feature
>in a single administrative environment?

depends on the size of the domain - clearly MLPP is for the largest of 
domains, making this uncertain at best

>But, I also don't understand your usage of the term "mobility"
>in this context. Is it personal mobility ? terminal mobility?
>or some other thing... If so, you need SIP  REGISTER request
>and DNS SRV to do the magic.

Does SIP REGISTER tell a CAC IP PBX the bandwidth required for a given 
call? Does it add up all the bandwidths of existing calls on a given router 
interface? Without that information - how can that IP PBX do effective BW 
control to the point of preempting existing calls because there was no more 
BW available at a given precedence level?

BTW - how does an IP PBX know the utilization of a router interface?

>But, that doesn't answer signaling
>for mobility. I presume, nsis should be focusing on those
>important questions(?).
>
>_______________________________________________
>Ieprep mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ieprep

cheers,
James

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

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