fataldata

Well we finally got an answer to a problem we've had with our last upgrade. Just FYI to everyone if you plan on going IP connect be aware that modem connections will not be supported.

We upgraded one PN to IP connect. After that modems no longer work from that PN to any other PN. Modem connections do still work between extensions within that PN. Perhaps Avaya never intended to support modems however we used a business partner who was unaware of this fact and failed to recognize this problem before our upgrade.

__________________
Systems In Use:
S8700 CM3.0 and S8710 CM3.1.1

martinyoung

If you had gone Multiconnect, would this have avoided the problem?

__________________
Marty
Retired Avaya DSIC tech

PBXtech.info

 

fataldata

Our network is Multi I believe. Most of our PN's are connected via fiber links to DS1C's, EI's etc... This one G650 PN is now connected via IPSI, CLAN and MedPRO to a Routed T1. I don't believe it is possible to have DS1C's and be IP connect. We are offered the alternative of putting local trunks in the remote PN and routing modems over them, but it kinda defeats the cost benefits of VoIP.

What it looks like is that if your modem call has to traverse the MedPRO bearer path, it will fail.

__________________
Systems In Use:
S8700 CM3.0 and S8710 CM3.1.1

martinyoung

It is Multiconnect because of the variety of port network connectivity you have. This remote PN is obviously not an LSP because it is only a G650. Since you have been talking to Avaya, I will assume the IPSI,CLAN, and MedPro firmware is current.

I must confess this is not a problem I have run into before, I wonder if it is new with CM3. Thanks for the heads up.

Since it is a G650, not everything is IP. Would a modem pool work for you? It would probably have to go at the S8700 to avoid the MedPro issue.

__________________
Marty
Retired Avaya DSIC tech

stubborne

Interesting problem. At what speeds are you trying to connect? Have you tried lowering the baud rate? How about your QoS configuration, have you looked at how much BW you are allowing? Are you doing compression? There are ton's of things that could cause your problem (or fix it).

__________________
Stu

fataldata

Yes it is.

I just got a call from a friend saying that he heard CM3.01 fixes this but I am waiting to have a conversation with him to verify.

Hmm, a modem pool. How do you mean? Not sure how I can avoid the MedPRO's bearer path barring the installation of local trunks on the PN.

Thanks everyone for your attention to this matter. I will keep you posted with our progress.

__________________
Systems In Use:
S8700 CM3.0 and S8710 CM3.1.1

PBXtech.info

 

fataldata

Well modem connections are functioning at 9600 when connecting two extensions within the same PN (so no MedPRO's involved). I have played with lowering the Baud down to 1200 to no avail. I'll have to check QoS and BW although BW shouldn't be an issue since the problem exists even during off hours when almost the entire PN is idle. Our current compression is G711 but I just tried with G729 with no success. Guess that makes sense since 729 is more compressed than 711.

__________________
Systems In Use:
S8700 CM3.0 and S8710 CM3.1.1

fataldata

Success!!!!!
Well, I dunno but I have made 2 successful connections so far. Minor instances of Packet loss but the connections succeed. I will keep verifying but here is the change that was made.

Ch ip-codec-set x
on page 2 change modem Mode from 'off' to 'pass-through'

Could have sworn we tried this before, but now our medpro's have all been replaced with updated hardware. Thanks all for your attention.
Perhaps I jumped the gun saying Avaya would not support this, but that's what happens when your info comes from our partner I guess. That's the info provided to me at least.

__________________
Systems In Use:
S8700 CM3.0 and S8710 CM3.1.1

stubborne

Awesome!!!

__________________
Stu

ruudsplint

How about SIP?
We use CM2.2 and CCS2.1 to communicatie with SIP.
Modems do connect, even at 33.6K but performance is poor.
Fax is oke, don't use T.38 because it won't talk with the providers Cisco gateway :D
We use G711 codec and ip-codec-set modem is off else it won't work.
I gues it is the UDP protocol used by the RTP stream causing the poor modem performance.

__________________
Ruud Splint
ruud.splint@imtech.nl
www.imtech.nl

fataldata

We haven't started using SIP yet, but I would assume the problem would have been similar. I think the issue was old hardware (MedPRO's). As for the modem being off. Our's was set to off and it wasn't until I set it to pass through that I could get it to work. Since our business is tourism, we aren't going to put this solution into full production until after the New Year. Previously when our vendor mentioned that it wouldn't be supported, we had designed a work around bringing in PSTN analog lines.

__________________
Systems In Use:
S8700 CM3.0 and S8710 CM3.1.1

hutch297

I just finished resolving this very problem for a customer, (it took much time and checking because of multiple issues). Fax and modem work good for the customer now. The customer has verified that all is working fine, both modem and fax, so here are the things that I would recommend for anyone in the future:

1) Set your Medpro and ethernet ports to non-negotiate, 100MB/Full duplex. Trust me on this one or you will get intermittent problems.

2) Make sure your TN2302 is a HW20 or better. I had specific problems with a TN2302 HW3 that was supposed to work according to Avaya.

3) Ensure that you're using the latest and greatest firmware.

4) On the 2nd page of the IP-Codec form use "passthrough" instead of relay. You may try setting your packet retransmit to 1, (sends duplicate packets). This generates additional bandwidth but on a LAN it shouldn't be a problem.

5) Use G.711 rather than a compression codec

6) Normal standard practice of disabling all of the unnecessary station features on a fax or modem, such as call waiting, testing, switch-hook flash, etc, but leave data privace enabled.

7) Use a method of QoS on the network so that voice related traffic gets priority over data, (modem and fax are considered voice as compared to email traffic).

Disclaimer: If you don't have a network that is capable of providing QoS for voice or are trying to connect remote sites through a small WAN link, I can promise you that you will have problems with fax, modem, voice, anything that is time sensitive.