the sip calls are not routing properly fail with 488 Not Acceptable Here


Doc ID    SOLN228172
Version:    2.0
Status:    Published
Published date:    15 Oct 2020
Created Date:    09 May 2013
Author:   
Clint Gray
 

Details

After upgrading to CM 6 from CM 5, the sip calls are not routing properly

vcm-016-02.0.823.0
Publication Date: 27 December 2011

UPDATES:
Update ID Status Type Update description
------------------------------- ------------ ------- ---------------------------
02.0.823.0-20558 activated cold patch 20558 for 02.0.823.0 >>>>> SP6 20558 April 22, 2013


KERNEL-2.6.18-238.AV2a activated cold kernel patch KERNEL-2.6.18-

Platform/Security ID Status Type Update description
------------------------------- ------------ ------- ---------------------------

Messaging ID Status Type Update description
------------------------------- ------------ ------- ---------------------------


Latest SP for this load:SP6 20558 April 22, 2013

Problem Clarification

Before we upgraded to CM6, we had sites that are only allowed to take SIP transcoded calls as G729/a. This was working perfectly fine on our
CM5.2.1 system. After the upgrade, we performed test calls to all sites and noticed CM6 was rejecting showing the following message:

SIP>SIP/2.0 488 Not Acceptable Here (No Matching Codec or Encryption Algo)

Translations hadn’t changed when going from CM5.2.1 to CM6.2. I tried everything I could to try to get CM6 to accept the calls, but I was running
out of time on my change window. I had to remove transcoding completely, from our SBC, and send the call untranscoded as G711 to CM6. I had to make
changes on the IP-Codec and IP-NR below in order to accept G711.

Here is a breakdown of the call flow. These are an SBC to SIP Trunk configuration (IE. Direct SIP Trunk).

1. Call routes from SBC to Avaya SIP Trunk via Signaling Group 35 and Trunk Group 35. IP NR 55 is used for SIP Signaling and was using
IP-Codec 2 to only accept G729a. Media is on IP-NR 101, which was also using IP-Codec 2
2. Inbound DNIS/VDN 7036803 processed on vector 396 and adjunct route request is performed
3. Call is sent to VDN 7036802 on vector 370
4. Call is queued to skill 394 and sent to the next available agent.
5. Test Station 7033095; test agent login 7039999

Cause

Customer need to reconfigure the Cisco phone to not send “G729A” in rtpmap of SDP, or use a different codec.

 

Solution

This is not a CM bug. Problem is with “G729A” in “a=rtpmap:18 G729A/8000/1” of the SDP in INVITE from the Cisco phone:

v=0
o=- 685798 0 IN IP4 10.231.245.16
s=Cisco SDP 0
c=IN IP4 10.231.245.16
t=0 0
m=audio 35364 RTP/AVP 18 101
a=rtpmap:18 G729A/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Per RFC 4566, rtpmap attribute got the following format:

a=rtpmap: / [/ parameters>]

“G729A” fall into the encoding name field but it is not defined in RFC 3551, so it is consider as invalid encoding name by CM6.2 SIP stack and this rtpmap attribute with the invalid encoding name is being ignore by CM. Given there is no other audio codec in the “m=” line, the SDP is consider as codec less and CM sent back the 488 Respond.

Customer need to reconfigure the Cisco phone to not send “G729A” in rtpmap of SDP, or use a different codec..

You might wonder why it work in cm5.2.1. The reason is that CM6.x is using a different SIP stack from CM5.x, in which the CM6.x SIP stack only support Encoding Name listed in RFC 3551.


Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy