I have encountered an issue where Cisco AS5300 falls back to g711u after receiving re-INVITE whose SDP offer is identical to session's original SDP offer. Voxbone sends INVITE with following SDP:
o=Sippy 139030316 0 IN IP4 10.1.1.1
m=audio 18194 RTP/AVP 0 8 18 101
c=IN IP4 18.104.22.168
a=silenceSupp:off - - - -
Cisco sends 200 OK where m-line of SDP is:
m=audio 16448 RTP/AVP 18 101
In 2 minutes the Softswitch that resides between Voxbone switch and Cisco sends re-INVITE to ensure that called party is still present. SDP of re-INVITE is equal (symbol-by-symbol) to that of INVITE.
At this point we see in debug:
Nov 13 06:05:01.739: sipSPICompareSDP
Nov 13 06:05:01.739: sipSPICompareStreams: stream 1 dest_port: old=18194 new=18194
Nov 13 06:05:01.739: sipSPICompareConnectionAddress
Nov 13 06:05:01.739: sipSPICompareStreams: negotiated codec changed from g729r8 to g711ulaw
Nov 13 06:05:01.739: sipSPICompareStreams: Flags set for stream 1: RTP_CHANGE=Yes CAPS_CHANGE=Yes
Nov 13 06:05:01.739: sipSPICompareVersionSessionId: No Change in sessid/versid but change in codec/addr/port !!
Nov 13 06:05:01.739: sipSPICompareSDP: Flags set for call: NEW_MEDIA=Yes DSPDNLD_REQD=Yes
The question is why Cisco falls back to g711u in the first place. Inbound dial-peer is configured with voice-class that allows g729 and g723 only (g711u is not even included!). IOS version is C5300-IS-M, Version 12.3(19).
I have made some tests by injecting various SIP messages and found that the issue is solved if we send re-INVITE without SDP body and with Content-Length: 0, but this is not acceptable solution. Please advice.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...