3rd Party SIP Phones feature codes

[Saaggs]

Good afternoon,
I am running an AVAYA AURA R8 platforms. I am trying to make third party SIP Phones work with SM/CM.
I can register the phone properly to both SM and place calls. However, I am trying to make feature codes work, at this time, I can see in traces that the feature code is sent to the CM via the SM trunk but CM does not do anything and it times out.
Do anyone of you know if feature codes can work with third party phones ? Or does it work exclusively with AST/PPM compatible devices ?
I am using a fanvil phone to test (H2U).

Thanks guys.

 

[Shaun E]

I haven't had problems with feature codes on third party SIP devices here (although some features codes do need you to dial the entire sequence before sending rather than just the FAC and getting a dialtone).

Most devices also use # as the "send" key so if you're using # as part of your feature codes you'll probably have to adjust the dialplan on the device.

Are there any codes you're struggling with? Happy to test on my 8.1 deployment.

 

[Saaggs]

Hi Shaun,
Thank you for your answer. I am not able to do the Call Forwarding All FAC for exemple (*31 in my case).
We do use # in FAC (deactivate in general) but I will change if that is necessary, thanks for the tip.
I am running 8.1 as well, to make the feature code go to CM I had to add a dial pattern with *31 in the SMGR (I do not remember doing that with Avaya SIP Phones but that was a long time ago).
At this time I am trying to get the call Forwarding all enable/disable codes to work.

 

[Shaun E]

Hi Saaggs,

Just did some testing using Bria and the Call Forward All FAC worked fine.

However having to add a dial pattern to SMGR makes me think that the application sequence might not be set correctly in the user's session manager profile as this shouldn't be needed. Can you double check that you have done this?

 

[Saaggs]

Hi Shaun,
Sorry, I think I did not interpret the traces properly yesterday night.
I've deleted the dial pattern for the feature code, it is in fact properly sent to CM but the CM does not interpret properly it seems.
I've uploaded a copy of the SM traces, after receiving the FAC, the CM sends it back to the SM100 (I am not sure if that is working as intended or if thats wrong).

When I'm doing the FAC from an H.323 stations, I do not have this behavior.
I should receive one J159 this morning that will configure for SIP to check if I have the same problem.
Thomas

 

[Shaun E]

Does anything come up if you do a trace on the station or the trunk group on CM itself?

Here's an example SM trace from mine using Counterpath Bria as the 3rd party SIP client.

 

[Shaun E]

I don't know why that attachment didn't work... let's try again.

 

[Saaggs]

On the CM I only have the same error (404 no route available) on the station or the TG :

10:48:53 SIP<INVITE sip:*311007@sip.cerba.local;user=phone SIP/2.0
10:48:53     Call-ID: 68375342022202442749@192.168.100.13
10:48:53     term trunk-group 998      cid 0x1795
10:48:53     route-pattern  998 preference 256  location 388 cid 0x1795
10:48:53     seize trunk-group 998 member 215    cid 0x1795
10:48:53     Calling Number & Name 2092014 TISSERAND, Th
10:48:53 SIP>INVITE sip:*311007@sip.cerba.local;user=phone SIP/2.0
10:48:53     Call-ID: 18d57fdcca5541ee96c10c297671b2
10:48:53     Setup digits *311007
10:48:53     Calling Number & Name 2092014 TISSERAND, Th
10:48:53 SIP<SIP/2.0 100 Trying
10:48:53     Call-ID: 18d57fdcca5541ee96c10c297671b2
10:48:53     Proceed trunk-group 998 member 215    cid 0x1795
10:48:53 SIP<SIP/2.0 404 Not Found (No route available)
10:48:53     Call-ID: 18d57fdcca5541ee96c10c297671b2
10:48:53 SIP>ACK sip:*311007@sip.cerba.local;user=phone SIP/2.0
10:48:53     Call-ID: 18d57fdcca5541ee96c10c297671b2
10:48:53   denial event 1166: Unassigned number D1=0x9d2e D2=0x201
10:48:53 SIP>SIP/2.0 180 Ringing
10:48:53     Call-ID: 68375342022202442749@192.168.100.13
10:48:53     idle trunk-group 998 member 215    cid 0x1795
10:48:53     active announcement      1009997 cid 0x1795
10:48:53     hear audio-group 1 board M2 ext 1009997 cid 0x1795
10:48:53     Connected party  uses private-numbering

 

[Saaggs]

Hi, I've tried the same thing on an Avaya SIP phones (J159) and I have another behavior, I am not able to dial past *31.
I also noticed that the ARS Access code is not deleted when placing a call with SIP Phones. (when calling 00180430095 for exemple, the CM should delete the leading 0).
I don't think the problem is with my 3rd party phone now but with my configuration between SM and CM maybe.
Thomas