Subject: RE: [Ieprep] deja vu

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

At 03:50 PM 11/21/2003 -0500, King, Kimberly  S. wrote:
>James,
>
>I'll write more of "a solution" using a QoS appliance.  An IP-PBX solution
>is something you can work on... :-)
>
>I'll put a smart QoS appliance on each LAN just before the WAN link.

Just like a Firewall - ensuring no packets get by this IP-PBX without its 
knowledge, or is this IP-PBX in a DMZ, or is this IP-PBX merely "near" the 
LAN to WAN router? What about LANs that are really big, requiring not just 
redundant paths (meaning there MUST be at least two such IP-PBXs - one per 
path), but one per path/redundant path pair. What about redundant IP-PBXs - 
ensuring one "just before the WAN" failing doesn't fail the system?

This is getting expensive.

>If SIP
>signaling traverses that link, the callee is not local and subject to being
>tracked and counted.

This will only work in SIP if the packet has the CAC IP-PBX in its IP DA 
field; otherwise, the packet will slip on by

>If signaling doesn't traverse it then it's a local LAN
>call and it can be ignored (assume LAN bandwidth is not a problem).
>
>This means I want some local proxy that knows what users are local and can
>resolve what local address it goes to.  I also want proxies in the core that
>tell exactly where the endpoint is.

Meaning there is no e2e encryption.... interesting

this also forces packets to take paths that are not efficient - which is 
not an efficient use of precious resources

>I don't want to redirect through a LAN.
>That ought not be so hard to ensure even if it takes a kludge with some
>redundant information.

Why should we design/model/build to a kludge?

Why not get it right the first time?

>This should take care of the issues.  It's the big picture of a particular
>solution.  One can nit pick forever and nobody proves anything because the
>requirements aren't there to examine and show that a solution meets them or
>not.

requirements are one thing, evidence that something doesn't work makes the 
requirement(s) moot

What actual, tangible analysis has been done to justify this big picture 
being presented here?

>Anyone want to write up the problem to be solved and some of the
>constraints?

It seems that most on this list aren't qualified to do such a task, as the 
requirements of this type of network are not complete or consistent. Given 
that fact, how can a problem be written up?

>Kimberly

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