NitramTELEBOY,
the medpro board is just a bunk of dsp resources for voip. it is used only when any one leg of a call involves voip. let's see some examples with s8700 multi-connect and two epns, assuming for simplicity that we're always using g.711 codec and no shuffling/hairpinning:
1. a digital extension calls another digital extension in the same epn. the call goes over tdm bus that interconnects all carriers in the epn, it does not involve voip so medpro resources are not used.
2. a digital extension in epn1 calls a digital extension in epn2. call path lies over tdm bus from digital port circuit pack to medpro, then it packetizes tdm stream and pushes it over to the second medpro in epn2, thus consuming one resource in epn1 and one in epn2. on the epn2 side, the process goes vice versa: ip stream is converted into tdm stream and tossed over to digital circuit pack 2.
3. an ip extension calls a digital extension in epn1. ip extension's network region is tied to epn1 network region. one medpro resource in epn1 is used.
4. the same ip extension calls a digital extension in epn2. this way one medpro resource in epn1 and one in epn2 would be used.
5. the same example but with shuffling: ip extension tied to epn1 calls digital extension in epn2. voice path is shuffled so epn1 medpro resources are not used, only one resource in epn2.
6. and the last example with shuffling: an ip extension tied to epn1 calls another ip extension tied to epn2. due to shuffling, no medpro resources are used at all.
mind that these examples describe
established voice path between two extensions. when an ip user picks a handset and hears dial tone, the tone itself is generated either by the tone generator circuit pack like tn2182 or ipsi board, but packetizing and compression is done by the medpro so there are two circuit packs used for providing dial tone. when user begins to enter digits, voice path with dial tone is cut off and system begins collecting these digits. depending on the ch sys ip settings, these digits may be passed from the phone to system either like dtmf codes in the voice path (medpro resource is still used in this case) or in form of call control sequence packets, and in this case medpro resource is not used. when user finished entering digits, system routes a call and depending on the success or failure generates needed progress tone. to provide this tone, again both tone generator and medpro are used, even if the call was placed to another ip phone and shuffling is on. remote phone is alerting, local user hears alerting tone, medpro and tone clock are in use. when remote ip user picks his handset, both phones shuffle voice path and ip stream goes between phones, medpro connection is dropped.
whew. i hope i helped to make it clear.
p.s. that's why i'm always advising not to try designing voip systems without deepest knowledge of how it ticks. there are just too many hitches to consider. and if you think the scheme i've described is too complex, try to think about different codecs, bandwith planning and call admission control, voip resource planning, qos planning and implementation in heterogenous networks, voip quality monitoring, vlan differentiation and aggregation, failover ip routing, firewalling and address translation schemes, security issues... i can go on and on.
)
