DTMF mismatch from new carrier

[HarryK]

So I'm kind of caught in the middle of a fight between vendor and new carrier right now. We previously had working service from an old carrier, but (Bigger Corp) bought them out and shut down phone service. My company is in a remote spot with not a lot of options and we've turned to the next best thing in the area for phones. We also have a support contract through Blackbox and they're pretty good about fixing our system.

The setup is Carrier> T1> 4 PRIs> Mitel3300-mxe

Now the new carrier has a "soft switch", so they're SIP based on their back-end I assume. I have zero SIP functionality on my end.

After the cutover, we stopped getting DTMF signals for voicemail and auto attendant. Packet captures from the carrier show signal going down to PRI, captures in the switch show zero activity. Find out it's a DTMF mismatch and they tell us to change to RFC2833...... which is a SIP protocol.

My support and their techs fight over who needs to change what, and eventual Mitel takes a look at my switch and says "um, yeah you don't have SIP, this is a provisioning error from carrier".

We also had weirdness where only 1/4 of the calls to DIDs were getting through, temp fix by cutting down to one PRI.

Still getting some pushback from carrier, but as of writing they sent the exact config for our service. Haven't had time to dig into it but my Blackbox rep had some interesting things to say about it. Does this make sense to anybody?


Framing:  ESF

Line Coding:  B8ZS

PRI IG index:              230

PRI IG Label:              my company no you can't know

PRI NFAS:                  disabled

NFAS D-Channel Backup:     disabled

NFAS Primary DS1:          1

NFAS Secondary DS1:        2

NFAS Active Path:          none

Admin State:               unlock

Operational State:         enabled

Emulation Mode:            network

Bearer Capability:         speech

Profile Request:           off

PRI Switch Type:           isdn2

PRI Trunk Selection:       Round Robin

PRI Timer 200:             1

PRI Timer 203:             30

PRI Timer 306:             10

PRI Timer 309:             90

PRI Timer 310:             30

Calling Name Delivery:     publicnet

Calling Name Presentation: publicnet

Calling Name Max Wait Time:750

Ring Generation Control:   auto

Called Party Type:         unknown

Calling Party Type:        unknown

Trunk Group:               none

Trunk Context:             none

NPA for Global DN:         Not Used

Global DN (minus NPA):     Not Used

GDN for outgoing calls:    no

 

INS Lines:                        48

OOS Lines:                        0

Unlocked Lines:                   48

Locked Lines:                     0

Enabled CRVs:                     48

Disabled CRVs:                    0

Enabled Lines(Broadband):         48

Disabled Lines(Broadband):        0

[v2win]

What type of device is handing off the PRI's to you and who manages that device?

[johnp]

If you are still getting a T1 hand off and all else is carrier equipment, they are to blame.

[HarryK]

What type of device is handing off the PRI's to you and who manages that device?

Wiring is crazy, but i think it comes into the building through FLM 150 ADM, then 66 block and then PRI circiut. All the carrier probably.
Tried to do pics but didn't work.

[acejavelin]

PRI is basically an industry standard... NI-2/Bellcore and signaling is done out of band (in the US at least) and have been around for 20 years, they are pretty much plug and play with only a few minor difference from one to another now days.

The DTMF issue is pretty simple... They are doing RFC2833 which is fine and largely not relevant, but the Adtran (or whatever SIP-PRI gateway they are using) is not converting the digits to inband DTMF properly to pass through the PRI to the AA/VM.

Honestly, if a carrier can't figure this out talking to a Mitel, one of the most common enterprise phone systems in the world, I would have to question the capability of the carrier... And I don't say that lightly, I work for a carrier and 90% of the time on our hosted platform, so I get where these guys are coming from... But SIP trunks to a PRI is not difficult stuff.

[johnp]

Honestly, if a carrier can't figure this out talking to a Mitel, one of the most common enterprise phone systems in the world, I would have to question the capability of the carrier... And I don't say that lightly, I work for a carrier and 90% of the time on our hosted platform, so I get where these guys are coming from... But SIP trunks to a PRI is not difficult stuff.

Regardless of Mitel, this would be to any system that has PRI capabilty. I agree with this assessment

[HarryK]

The DTMF issue is pretty simple... They are doing RFC2833 which is fine and largely not relevant, but the Adtran (or whatever SIP-PRI gateway they are using) is not converting the digits to inband DTMF properly to pass through the PRI to the AA/VM.

Fiber comes into the building and hits a Fujitsu FLM 150 ADM, would this be the gateway that needs configuring or something else like an adtran farther up the line? I don't think their techs touched this when the cutover was done.

[acejavelin]

The DTMF issue is pretty simple... They are doing RFC2833 which is fine and largely not relevant, but the Adtran (or whatever SIP-PRI gateway they are using) is not converting the digits to inband DTMF properly to pass through the PRI to the AA/VM.

Fiber comes into the building and hits a Fujitsu FLM 150 ADM, would this be the gateway that needs configuring or something else like an adtran farther up the line? I don't think their techs touched this when the cutover was done.

Typically, your PRI gateway device is what you connect your PBX to from the telco, this is what converts the IP SIP signal to an ISDN PRI service. Adtran devices are just a common one, but there are others like AudioCodes, Mediatrix, Grandstream, Sangoma Vega, Patton, Digium, Yeastar, and a multitude of others... My suspension is that device is not configured properly.

Sent from my Pixel 3a XL using Tapatalk