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.