SIP Conf Phones cannot dial 1 to enter WebEx Call 1

[avayatech2018]

So recently discovered an issue where if you answer the incoming WebEx call and press 1 to connect to the WebEx from a SIP conf phone it fails. Works fine from my 9611g desk phone which I believe is running H323. I have two SIP conf phones that I know have this issue. We have SIP trunks doing a PRI handoff to our Avaya CM 6.3. Calling out on the Conf phones is fine. Just curious if any of you have run across this in the past? Been reading up on it but have not figured out the issue yet.

40 years in Telecom. New to Avaya! Go easy.

 

[kyle555]

So what's the call flow?

SIP Conf phone to SM to CM.

Then CM has a PRI tie to something - pretend it's an Audiocodes M1000 - that gets you SIP to the PSTN?

Whatever it is, it'll be key that the DTMF is in-band over the PRI outward to the SIP trunk. And if a H323 9611 works, then you know that much is happening and the M1000 is hearing in band DTMF and sending it to the carrier the right way - in-band or RFC2833 or whatever.

Can the conference phone dial out to the Webex bridge and key in the meeting ID?
If so, was the conference phone dialing out the same path and thru the same hops that Webex took when calling inward when the 1 wasn't heard?
Regardless, can the conference phone pass DTMF to other things - like pressing 1 in a vector in CM or calling voicemail and logging into a mailbox?

 

[avayatech2018]

Kyle I was able to call voice mail from the conference phone and access my mailbox. The SIP comes in on an AT&T IPFLEX router and then connects to a Lucent 120A2 CSU Module on the back of a G650 cabinet and then to a TN464GP DS1 card. It sounds right having the SIP Conf phone to SM to CM. And I was able to call into a webex meeting by dialing the access number and then the meeting number.

40 years in Telecom. New to Avaya! Go easy.

 

[kyle555]

I'm sure you can set it in the SIP conference phone whether it should be sending in or out of band DTMF.

Presumably it's out of band/RFC2833 because that's the 'right' way. And presumably your voicemail is SIP too.

I'd be curious if inbound calls from Webex are truly taking the same path thru that IP Flex as your outbound calls. If so, at the end of the day, you're out of band 2833 DTMF hits the medpro on the G650 and gets converted to in band tone on the B channel.

Presumably the IPFlex box would then strip that tone out and translate it back to RFC2833 for transport in their network.

Still, "how tones work" shouldn't matter based on whether you're the called or calling party.

If you do a station trace on that conference phone and are absolutely sure that it's the same trunk group inward vs outward, then I'd bug AT&T

Still bugs me that your 9600s wouldn't have the problem. Are you absolutely sure the DIDs that ring on 9600s come in on the same trunk as the conference phone DID?

Just for fun, what if you put a brdg-appr of like 1 of the conference phone on a 9600, answered the call from webex to the conference DID on the 9600 and tried that?

 

[avayatech2018]

So Kyle I grabbed a SIP conf phone and placed it at my desk. I don't have a WebEx account so finally got someone to setup a conf so it could call me.

Grabbed a list trace. Interesting to say the least! The call starts out coming in on the proper SIP ISDN trunk group but then appears to take a turn? I see a "INVITE going via Sig Grp 98, Ignoring called number routing". Then I see it's dialing my 4 digit extension of my conf phone on a SIP trunk group 99. That particular trunk group is labelled Voice Mail. Although I have 2 trunk groups labelled Voice Mail. So very interesting how it's being juggled inside the Avaya it appears. I will see what I can figure out from this.

Thanks for your ideas!!! I appreciate your input.

40 years in Telecom. New to Avaya! Go easy.

 

[kyle555]

OK...
Now do the same thing with a brdg-appr of the SIP phone on a 9611 and see if the tones work on an incoming webex call.

You also want to figure out what that 'ignoring called number routing' means... why? Is there some denial event?

Normally your incoming digits would match a station - like the conf phone - and that station's last page would have how it gets to a SIP trunk - AAR, route pattern, trunk group number, etc.

I could talk for an hour about the differences of CM picking a trunk to send a ringing call to a SIP phone vs SM pitching an INVITE at CM representing a phone going off hook and CM picking which sig/trunk group should service that call. Short answer is it should always be the same sig/trunk group - and out of CM depends on AAR/off-pbx station-mapping and from phone-->SM-->CM depends on sig group numbering and far end domains.

But, if there's a difference in the sig group you get calling the conf phone vs the sig group CM picks for an outward call from the conf phone, then I'd look in the DTMF parameters of those two sig groups to see if there's a difference.

Namely, if the one you're picking from CM to the conf phone to deliver a call happens to have dtmf inband and the settings of the conf phone are out of band/rfc2833 (like it should be), then you could traceSM that call to the conf phone and see in the SDP something like "m=audio 2126 0 18 101" which means "send me audio on port 2126, I accept type 0 (711u), type 18 (729) and 101 (rfc2833 dtmf).

If you can find SDP when calling out from the phone with type 101 and SDP calling into the phone without 101 and just 0/18, then that would prove when CM to SM to conf phone happens that CM is only listening for inband tone from your SIP station - which it'll never send. And, that should also mean a brdg-appr on a 9611 H323 should be able to receive a call to the conf # and DTMF 1 to join. That'd prove a config problem for your SIP stations.

 

[avayatech2018]

Lots of good info. Thanks again. I'm almost out of here for today. But I will try the Bridged Appearance tomorrow. Learned something new. Looked at the last tab of my SIP conf station. SIP Feature Options. My SIP Trunk box has 99 in it. So that explains some stuff. Didn't know that was there. I'll do some more digging. But let me ask you this. There's going to have to be a SIP trunk connection to my Conf phone correct because it's running SIP. So there going to have to be a handoff between the AT&T SIP/PRI ISDN incoming connection and the SIP connection to the actual Conf phone right? So sounds like I need to look at my Signalling Groups more. All very interesting stuff. Thanks again for your input. It's fun learning new stuff. More tomorrow.

40 years in Telecom. New to Avaya! Go easy.

 

[avayatech2018]

OK so the bridged appearance on the 9611 worked. I can see in the trace that "digit 1 originated by station (my station)". Then "digit 1 sent to trunk-group 2 member 1" which is the SIP/PRI ISDN trunk the call comes in on. So even though part of the call is using trunk group 99 again to reach the conf phone it see's the 1 being dialed on my 9611 and sends it back out the proper trunk.

In looking at the SIP/PRI ISDN trunk group i see "Digit Handling" on tab 2 set to "enbloc/enbloc" for In and Out. If I look at the Signal group for Trunk-Group 99 I see "DTMF over IP: rtp-payload".

Anyway I'm still doing more digging.

40 years in Telecom. New to Avaya! Go easy.

 

[kyle555]

Perfect. So we know it's about how your SIP conference phone makes vs receives calls.

Now...here's where the SIP stuff gets complicated. You're interested in the signaling group that your phone takes when dialing out vs when being called.
When being called is easy - in the last page of the station form you have 99. I suspect you're on CM6.3. Just 99 = trunk group. On 6.3 you can say 'aar' or 'trunkgroup#". On 7.x they added route patterns, so you need to say rp99 for route 99 or tg99 for trunk 99. They did that so you can have a route with choices to SM1 and SM2 and still hard code something at the station level but have some ability to failover.

Anyway, anything hitting the PBX for your conf phone goes out trunk 99. Trunk 99 has a "sig group" defined in the bottom right of the first page. You're saying that particular sig group is set to rtp-payload.

How CM picks your conf phone's sig group when you're dialing out:
SIP phone goes off hook, dials a number, whatever.
SM receives that and invokes the application sequence in the user's SM Profile
That app sequence has a SIP entity as destination (you'd see that in SMGR-->Session Manager-->Network Configuration-->Applications)
Notice that the Application Sequence specifies ONLY the entity of CM, not a specific entity link or port or anything
SM then sends the request to CM.

When CM gets a SIP request, it needs to figure out which signaling group its associated to. Think of the whole system like a tree. SM is the tree trunk, the branches of SIP phones are on top, and CM is the root system underneath. Yes, it's true that many aspects of the system design are in the roots and the branches, but it's also true that messages from the branches need to feed through the trunk to get to the right roots.

In terms of PBX design, it would be perfectly normal to have 1 CM in a data center with 1 SM feeding many different sites and applications. It would also be normal for CM to have many sig/trunk groups to SM, but SM still only has 1 entity/link to CM. Remember - CM has a concept of channels/trunks - SM doesn't. If you need 1000 channels up to SM for something, you're building 4x trunk/sig groups for it while on the SM side, it still only has 1 entity/link to CM.

Now, take that example of 1000 channels on 4 trunk groups. Suppose they're on the same IP/port for the CM and SM side. How does CM pick a sig group when SM sends a call inward?

The rule is:
CM will look at the near/far IP/port and list all sig groups that are a match.
Next, it will compare the domain of the request - 1234@pbx.company.com.
It will consider a match ANY signaling group that has, as far end domain, something that fits into pbx.company.com
That means all sig groups with far end domain pbx.something.com AND all sig groups with FE domain something.com are matches.
CM lists the matches and the winner is the sig group with the lowest number in the system.
What that means is if you're going to have elaborate subdomains is that ivr.east.company.com should be sig group 1 and company.com should be sig group 999. To say, your most elaborate subdomains should be the lowest numbered signaling groups so they would explicitly not match 1234@pbx.company.com.

If you happen to have a sig group 1 with far end domain company.com, then what you're doing is forcing all traffic from SM to CM thru that sig group, be damned if its a SIP phone calling out, a PSTN SIP trunk on a SBC, or AAM calling out to use a reach me feature, and you have no segregation of handling of call types coming to CM via SM

So, back to your problem, you should try to find out what sig group you're using when dialing OUT from the conference phone and compare those DTMF settings to the sig group it receives calls on.
And, don't kill yourself - what kind of conf phone is it? Their passwords are usually 123 or 456 for polycoms, they all have a web page for the most part, and you can see what its DTMF settings are.

I still find it odd! If you're in-band on the phone side, then Avaya be damned, even if Avaya's going to you with out of band settings, if the phone is in band, the tone should make it in the speech path across the B channel to the AT&T box listening. And if your conference phone is RTP too, then inbound calls using the sig group with RTP payload shouldn't even be a problem.

Anyway, there's a little crash course in why a lot of Avaya SIP networks are goofy. They really didn't socialize these concepts when people were putting them out for the first time, so there's a lot of less-than-ideal config out there that's harder to untangle than 'just doing it right'. Doing it right 5 years ago wasn't easy!

 

[avayatech2018]

Kyle thanks for the lengthy write up. I appreciate the info. I'm still looking at stuff. One thing I found which I totally overlooked was Tenant and location. My test conf phone was in a tenant group and had location info I was overlooking. I believe that's why I was seeing some crazy trunk group stuff which made no sense. I will update what else I find. Getting ready for the Holiday weekend. Hope everyone has a Happy Thanksgiving!

40 years in Telecom. New to Avaya! Go easy.