Calls to SIP user won't go to Cell when set up in One-X Communicator 6.2

[learningSkype]

this is very strange. i have my Avaya extension built as a 9630SIP phone. because of dual registration i have a physical 9630 set as well as one-X Communicator 6.2 on my laptop.
i can use deskphone or softphone app at any time and have both registered and place calls any way i want, no issues.
while trying to help a user today she told me that her one-X doesn't send calls to her cell when she sets the "Place and receive calls using" option to "Other Phone" and selects her cell as the choice. she added her cell in the app via the Phone Numbers option in General Settings[/b]. she also selected "cell" under Outgoing Calls. everything looks correct. when she opens up One-X she selects "cell" for "Place and receive calls using", and she then logs in to her softphone. that piece is fine so when i call her the call should ring her one-X app as well as her cell. it never does...the call rings just the one-X app 3 times and goes to voicemail.

what's even stranger is that if i do the exact thing on my one-X softphone and add her cell in "Phone Numbers" under General Settings, and log in to my softphone and then dial my extension from another phone nearby, the call rings at my desk then starts ringing her cell. bizarre!!

so i traced both calls and found 1 little detail:

calls to my extension show the caller ringing to my extension, then over to my cell,
but
calls to her extension never ring to her cell. i see a 480 Temporarily Unavailable (SIPS Not Allowed) message in parts where the call should be ringing her cell phone.

i thought it might be ec500 related so checked her station mapping, it's set to OPS and her current phone number and config set are set to 1. so, i'm stumped. wondering if anyone here has some insight. last, i compared her station build to mine in CM, all settings are identical. checking SMGR next to see if anything jumps out at me.

 

[DAVIDPAYNE]

Have you check COR, Tenant? Did you check all of the setting in One-x? In the trace did you see the digits that where trying to be dialed?

 

[learningSkype]

Yes, COR, tenant match mine as well as all the settings in One-X. the only difference between her phone and mine is that i have 3 entries in CM for station-mapping (ec500):

i have 2 entries for One-X and 1 entry for OPS.
she only has one entry for OPS

 

[LoPath]

I haven't been an Avaya guru for a while, so this may be totally off-base.... but I had a similar issue with my Unify PBX. Would the carrier be Sprint perhaps? In my case, it wasn't allowing me to forward an incoming call from a Sprint cell phone. I found that their ISDN setup message is different than the rest - indicating "Origination address is non-ISDN". That would throw off the PBX. For the HiPath 4000 PBX, I had to ensure I included TEL3K1 as a service type for forwarding. Maybe this will spark some ideas?

LoPath
Maintain HiPath 4000 V5 & V6, OpenScape Xpert V4 & V6, OpenScape Xpressions V7, OpenScape Contact Center V8, OpenScape Voice V9

 

[learningSkype]

it's not a carrier issue. i can take the same cell phone and add it to my One-X app and it works. it's either the station-mapping portion or something to do with CES.

 

[kyle555]

In the EC500 mapping, you define how the call hits the PSTN - either by trunk group number or ARS.
As a test, put the trunk number in.
As far as I know, the ARS location would be selected as a function of the registered phone - the desk phone or one-x.

When doing it from your One-X in your network region/location vs her doing it, would the outgoing trunk selected be the same? Either way, try in her EC500 by just popping a trunk group number in and not ARS.

The reason I say that is because if you hit ARS, you then hit a route. In the top of the route pattern is a Secure SIP? option that will enforce a SIPS URI. As I understand it, the difference between a SIP and SIPS URI is that SIPS indicates it requires TLS over every hop to get to the destination. To say, it's illegal for a proxy like SM to get a TLS SIP invite with a SIPS uri and pass it along to another hop like a SBC which is likely TCP or UDP.

The reason for all that is if you do media encryption, the keys are exchanged in the SIP signaling. So, a TCP SIP phone on SM can't do encrypted media. Or, a TLS SIP phone on SM with a TCP trunk down to CM can't do it either. You have to be end-to-end TLS to negotiate encrypted audio.

Anyway, if her ARS location/route preference happens to have secure SIP at yes in the route, and her station's ARS routing to the PSTN was via SIP trunks and most likely your SM-->SBC trunk was not TLS, that'd be a great reason to get the failure you're seeing.

 

[learningSkype]

Kyle, she doesn't have ec500. all she has is OPS for the Application field in station-mapping and then her actual extension is listed for phone number and AAR for trunk selection. basically it looks like this:

Applcation

​

Phone Number​

Trunk Selection
OPS

​

​

12345

​

aar​

 

[learningSkype]

sorry, that looks bad. try again:

Application = OPS
Phone number = 12345
Trunk selection = aar

 

[kyle555]

still, hows the route pattern look?

 

[joe2938]

Should be ARS I believe

 

[kyle555]

oops. my bad, yeah, not ec500, but 'other phone' from the soft client

regardless, if she's 'other phone' then whenever something rings her set, her softclient dials the 'other phone' number - so if that 9-1-555-555-1234, she'd hit ARS. Whatever it is, just pretend the softphone is dialing that number in 'other phone' - maybe with or without dialing rules in the softclient, but in any case, the softphone is placing that call from it's network region/location.

If you're hitting AAR/ARS and a route and then a trunk, the route can still be the thing enforcing SIPS uri. If the route hits a TCP trunk to SM, SM would reject with the 480. If CM-->SM is TLS but the result of the dial pattern is to a SIP entity to which SM only has a TCP or UDP link, you'd get the same.

Either way, Avaya sneaks some descriptions in the error codes - like 480 Temp Unavail (SIPS Not Allowed) - that SIPS Not Allowed part probably came from a CM or SM to give you a hint of why it's 480 Temp Unavail.

 

[learningSkype]

thanks all. Kyle, even though i agree with you, i ended up just adding an entry for ec500 in the station-mapping. then enabled the feature on her phone and it works now. yes i could've gone the troubleshooting route and spent more time trying to find out why the call was failing but i think it's has to do w/the point you made above. it's certainly something between the trunk and SM but it's working w/the ec500 add so i'm going to move on to other things. plenty of more work, that never ends...