NEED BIG HELP ON Med-Pro question? 2

[NitramTELEBOY]

Is there a way to pinpoint an internal extension to the med-pro resources being used for a call.
It doesn't have to be IP phone, but a normal TDM phone placing an call internal or external over a TDM/PTP trunk or an outbound T1.

If you guys & gals can help me with this one, the forum truly is the holy grail of telcom technology!!!!!!!

THanks.

 

[4merAvaya]

The MedPro board is dynamically allocated. I know of no specific way to identify port usage. The MedPro is only used for calls involving IP endpoints, either station or trunk.

Kevin

 

[NitramTELEBOY]

It is my understanding that the med-pro acts as the tone generator in the G700 within the cm2.0 enviroment.
So if I go off-hook, and don't have a tone-generator card it's the medpro supplying that resource of tone.

 

[schned99]

There is no MEDPRO in a G700. You can only put MEDPROs in G650, MCC, SCC, or CMC1 Media Gateways. MEDPROs have no tone generation resources. I suspect there is a tone generator built into the Media Gateway Processor (MGP) on the G350 and G700 Media Gateways.

 

[NitramTELEBOY]

Sorry, I meant g650. Doesn't all calls utilize the medpro resource if I have an IP connect s8700?

 

[schned99]

The G650 gets it's tone from the IPSI that controls the port network. The IPSI has all the same TTR and tone generation resources at the TN2182. It only uses the MEDPRO resources for call path to other port networks.

 

[schned99]

Or for IP Phones and Trunks also, of course

 

[phonegoober]

if you status the station while on an IP call, it will tell you what medpro resource you are using. albeit, IP to IP or a hairpinned call.

 

[NitramTELEBOY]

So all my calls route from one switch to the other on IP trunking, but the call is placed on a regular TDM/Digital set to another digital set; WHAT IS MY CALL SETUP & BEARER TRANSPORT MODULES?

The same question if I am going from digital set to IP telephone set? Again, the trunk connecting the two seperate PBXs is IP H.323.

Thanks

 

[NitramTELEBOY]

phonegoober,
It should not hairpin or IP to IP connect if the calling phone type is a digital phone, only if it's two IP phones.

 

[schned99]

Intra-Switch Communication (IP Connect):

If a call is placed from one digital set to another digital set on the same port network, call set up and transport is TDM Bus.

If the call is placed from a digtal set on one port network, to a digital set on another port network, your call set up is CLAN and transport will be MEDPRO.

Inter-Switch Communication (H.323 Trunks):

The call placed on Switch A goes out over the IP trunks to Switch B. The H.323 Trunk Group on both switches has an associated signaling group that has IP addresses for the CLANs. Using the information in the signaling group, call set up is passed over IP between the CLANs and the voice (transport) path is MEDPRO to MEDPRO. The Media Processor of both systems will dynamically allocate MEDPRO resources and use the CLAN signalling connection to coordinate which MEDPRO IP address to send and recieve voice packets.

 

[NitramTELEBOY]

schned99,
This is great. Now can you do the tranlate the same two calls on a MultiConnect s8700 setup?

Secondly, what if my switch A is muliconnect and my switch B is IP connect. (These are seperate switched with their own s8700 as well as each has a remote sites hanging off of A & B respectively.)

Thanks.

 

[nohuhu]

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. )

 

[schned99]

Intra-Switch Communication (Multiconnect):

Call set-up and transport is TDM bus on the same port network. Call set-up and transport and trasport between port networks is still TDM bus extended over fiber links.

I do need to clarify that all of this activity in both multiconnect and IP connect environments is controlled by the processors via the IPSI control link.

dwalin's post above is an excellent start on VoIP planning and gives a good idea of numerous types of interactions you need to consider when implimenting VoIP. I've been working on Avaya converged products for years and each installation is different and has a whole host considerations that may only apply to that environment. When ever we do these types of installations we always have a group of design and installation engineers map the customer's topology, perform a network assesment, and then check and recheck all the interactions. Even with an extensive planning phase, there are always issues to be shaken out after installation.

 

[nohuhu]

schned99,

adding my two cents again: starting with cm3 there is now an ability to use ip-connected epns even in multi-connect installation. this scheme is called 'mixed connect' and in this case all said things about voip are applied of course.

 

[NitramTELEBOY]

Thanks to both you guys. Each of your comments/analysis are excellent and very clear.
I have been working on Avaya products for 10 years, and unfortunately for the last two or three mostly call center so I missed a lot of the little things with s8700 versus an "si" or "R".

Ideally I love to work on the PBX and going data was somethng I craved many years ago. That being said I missed out on the sys75 & 85 where a lot of "ole school" knowledge was picked up by technicians. My telecom life started without the basics of punching down sets or pulling cable.
In a way I never got my hands dirty, and I kinda wished I had. But I won't let it happen that way this time around with convergence!