Subject: RE: [Ieprep] deja vu

From: "James M. Polk" <[email-masked]>
Date: Fri, 21 Nov 2003 14:40:43 -0600

At 02:45 PM 11/21/2003 -0500, King, Kimberly  S. wrote:

>James,
>
> >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.
>
>Another guess...you used the words "each knows where a destination endpoint
>is".  Okay, I'll address that part more clearly.
>
>One doesn't need to know where the endpoint is.  If Joe moves his IP phone
>to another base, that's fine because the smart CAC and normal SIP address
>resolution/IP routing will take care of the problem.
>
>Why?
>
>Because the CAC doesn't just control who gets to place outbound calls, it
>also intercepts inbound SIP messages.

Not necessarily.

If LAN A has a Proxy that knows the IP address of UA2 on LAN B, it sends 
the SIP INVITE directly to UA2's IP address. This will bypass the Proxy in 
LAN B where UA2 currently lives.

>Suppose we are at a LAN with a link into the core network that can support
>24 quality VoIP calls.  Now suppose 24 are occurring and they are all
>routine.  An important call request comes in over that link from somewhere
>else.  CAC looks at the SIP message and the RP header says it's a priority
>call request.

So.... the CAC knows exactly how many calls exist on a particular link, how 
very much like a Gatekeeper this is looking.

What are the codecs used on each of these calls?

Have any of the calls changed codecs, thus bandwidths, to affect how much 
bandwidth is available?

Does the CAC know this?

How does it know this?

Does the CAC in LAN A have to know the presence of the CAC on LAN B?

What about LAN C?

What about LAN AZ, or FZ?

Does this approach scale?

Does each CAC have to be configured with every other CAC (by IP address?

What about multiple links out of a LAN into this core network?

>  So, CAC kills one of the existing routine calls and allows
>the priority one to setup.

Please re-read
http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-01.txt
because SIP Servers are not envisioned to act this way.

>We now have bandwidth on our access link (both
>at origination and where it is accepted).  The core is fine.  Life is good.

Life is good if what you're proposing knows about all of it and is aware of 
all of it in real-time all of the time....

>I don't think this problem is that hard but it must be defined or people are
>going to talk in circles.

How don't RFCs 2205, 2209, 2210, 2747, 2748, 2749, 2750, 2753, 2996, 3175 
and 3181 address this without creating this real-time CAC IP PBX that can't 
scale to meet the requirements?

At the end of the day, you are suggesting using out of band signaling to 
control the number of sessions on the data path. Only in-data-path 
signaling can properly control data path sessions.

Remember the Flows ID.... this was the point made there

>I'm getting dizzy and I'm a levelheaded woman.

Hey.... you volunteered to be WG chair here....

>:-)
>
>Kimberly
>
>_______________________________________________
>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