Avaya Aura CM SIP Trunk to Cisco CMExpress 1

[CChambleeJr]

ISSUE # 1 -

At present, calls can only be placed from the Avaya side to the Cisco side over the SIP trunk. When calls from the Cisco side attempt to ingress via the SIP trunk, the originating caller receives fast-busy. While tracing activity over the SIP trunk I see no indication that the trunk even sees activity during this ingress call. However, the Cisco engineer that is engaged on the Cisco CME side advises that the CME is getting a message back from the Avaya server as follows:

=======

SIP/2.0 406 Server Not Acceptable (Server is IMS enabled)
From: "7975G at Con 2" <sip:2345678@xxx.xxx.xxx.xxx>;tag=D00140-2680
To: <sip:1234567@yyy.yyy.yyy.yyy>;tag=8088f5b9b8ade213a3c5156997600
Call-ID: 4E908798-B10711E2-8059CCFB-A19E884D@xxx.xxx.xxx.xxx
CSeq: 101 INVITE
Via: SIP/2.0/TCP xxx.xxx.xxx.xxx:5060;branch=z9hG4bKACEA
Server: Avaya CM/R016x.00.1.510.1

========

Where xxx.xxx.xxx.xxx is the Cisco CME router and yyy.yyy.yyy.yyy is the Avaya C-LAN handling the SIP trunk.

I have again verified the Avaya SIP-trunk related configuration is in place, as per the white paper sent to me by Avaya Support after opening the ticket with Avaya. Our Avaya CM is an Evolution Server, and currently has no SIP endpoints on the local side, only H.323 VoIP, digital and analog stations. I'm looking for guidance on troubleshooting this issue.

ISSUE # 2 -

When a test call is originated from Avaya to the Cisco CCM, specifically, through the Cisco CCM and over another SIP trunk (not Avaya associated) to an AVR server, the AVR server was not able to receive DTMF tones originated at the Avaya phone. There was, however a clear communication path between the two end points via voice. This was confirmed by examining the Wireshark packet captures on the Cisco side. The flip-side of this scenario, however, is that if the Avaya phone originates a call over the Avaya SIP trunk to the Cisco CCM, and to a Cisco "skinny" SIP phone, then we have both a clear voice path AND the ability to send/repeat DTMF tones from the Avaya phone to the Cisco phone.

Unless the Avaya SIP trunk configuration is somehow differentiating between these two Cisco endpoints, I see no reason that the Avaya SIP trunk can be held at fault for the lack of passing DTMF tones to the Cisco-side AVR server.

 

[jimbojimbo]

Couple of items to look at.

1. In the signal group look at the IMS enabled field.
2. Verify the SIP domain name of the Cisco matches the CM or you have the SIP domain properly programmed.
3. I believe you will need to use 101 (NTE) as the telephony event payload type (in the trunk group form) when connecting to the Cisco (I do this with Microsoft and I think it is the same with Cisco although I haven't looked in awhile).

 

[CChambleeJr]

Thanks JimboJimbo. That obscure setting, "Telephone Event Payload Type" change from 127 to 101 fixed my DTMF issue. Now if I could just get calls to go both ways I'd be rocking! Still can't get incoming calls over my SIP trunk from Cisco to Avaya... "406 Server Not Accepted" is the response the Avaya is sending Cisco.

 

[CChambleeJr]

I'm still trying to figure out why the Avaya CM is responding to the incoming SIP call with "406 Server Not Compatable". 406 seems to indicate that there is a discrepancy with the capabilities between each end of the call. If I compare the SIP invite messages between the Cisco subscriber originate and the Avaya subscriber originate, I see differences in the "Supported", "Allow", and "Content Length" data. Here's the invite from the Avaya side going to the Cisco side:

=====

INVITE sip:4508386@xxx.xxx.xxx.xxx SIP/2.0
From: "Blow, Joe" <sip:+2563130845@155.151.55.106>;tag=0e8e5a71aee216ca25156997600
To: <sip:4508386@xxx.xxx.xxx.xxx>
Call-ID: 0e8e5a71aee216da25156997600
CSeq: 1 INVITE
Max-Forwards: 71
Via: SIP/2.0/TCP yyy.yyy.yyy.yyy;branch=z9hG4bK0e8e5a71aee216ea25156997600
Supported: 100rel,histinfo,join,replaces,sdp-anat,timer
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,INFO,PRACK,PUBLISH
User-Agent: Avaya CM/R016x.00.1.510.1
Contact: "Blow, Joe" <sip:+2563130845@yyy.yyy.yyy.yyy;transport=tcp>
Route: <sip:xxx.xxx.xxx.xxx;transport=tcp;lr;phase=terminating>
Accept-Language: en
Alert-Info: <cid:internal@xxx.xxx.xxx.xxx>;avaya-cm-alert-type=internal
History-Info: <sip:4508386@xxx.xxx.xxx.xxx>;index=1
History-Info: "4508386" <sip:4508386@xxx.xxx.xxx.xxx>;index=1.1
Min-SE: 2400
P-Asserted-Identity: "Blow, Joe" <sip:+2563130845@xxx.xxx.xxx.xxx>
Record-Route: <sip:yyy.yyy.yyy.yyy;transport=tcp;lr>
Session-Expires: 2400;refresher=uac
P-Charging-Vector: icid-value="AAS:8986-5a0ee8001e2ae715651a26b7699"
Content-Type: application/sdp
Content-Length: 254

v=0
o=- 1366826466 1 IN IP4 yyy.yyy.yyy.yyy
s=-
c=IN IP4 yyy.yyy.yyy.yyy
b=AS:64
t=0 0
a=avf:avc=n prio=n
a=csup:avf-v0
m=audio 2476 RTP/AVP 18 0 127
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:127 telephone-event/8000

=====

And here's the invite from the Cisco side going to the Avaya side:

=====

INVITE sip:4508997@xxx.xxx.xxx.xxx:5060 SIP/2.0
Via: SIP/2.0/TCP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK31F51
Remote-Party-ID: "7975G at Con 2" <sip:4508386@xxx.xxx.xxx.xxx>;party=calling;screen=no;privacy=off
From: "7975G at Con 2" <sip:4508386@155.151.55.106>;tag=A22760-D52
To: <sip:4508997@xxx.xxx.xxx.xxx>
Date: Tue, 30 Apr 2013 19:09:26 GMT
Call-ID: 4F7BC99B-B10011E2-802BCCFB-A19E884D@xxx.xxx.xxx.xxx
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1304472179-2969571810-2150026491-2711521357
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1367348966
Contact: <sip:4508386@xxx.xxx.xxx.xxx:5060;transport=tcp>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 300

v=0
o=CiscoSystemsSIP-GW-UserAgent 6539 8807 IN IP4 xxx.xxx.xxx.xxx
s=SIP Call
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio 18726 RTP/AVP 18 101 19
c=IN IP4 xxx.xxx.xxx.xxx
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

=====

Note differences in the "supported", "allow" and "content length" fields between the two. Could one or more of these differences be causing the "406 Server Not Compatable" error?

 

[montyzummer]

Could be something to do with the sending method , can you change the sending id on the cisco to p asserted id?

APSS (SME)
ACSS (SME)
ACIS (UC)

 

[CChambleeJr]

When you refer to the sending method, which parameter(s) are you referring to on the Cisco side?

 

[montyzummer]

Im not that familiar with cisco but with sip trunks you genraly have a couple of settings on how you send the number format, on the cm you can use from or p asserted id , im guessing you must be able to affect this change on the cisco , as this could certainly be a reason for the cm not processing the info correctly.

APSS (SME)
ACSS (SME)
ACIS (UC)