AS5300 falls-back to g711u mysteriously

Unanswered Question
Nov 12th, 2007
User Badges:

Hello,


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:


v=0


o=Sippy 139030316 0 IN IP4 10.1.1.1


s=session


t=0 0


m=audio 18194 RTP/AVP 0 8 18 101


c=IN IP4 81.201.82.23


a=rtpmap:0 PCMU/8000


a=rtpmap:8 PCMA/8000


a=rtpmap:18 G729/8000


a=fmtp:18 annexb=no


a=rtpmap:101 telephone-event/8000


a=fmtp:101 0-16


a=silenceSupp:off - - - -


a=abcde:20


a=sendrecv


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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
andrew_pog Tue, 11/13/2007 - 00:40
User Badges:

Another way is to ask Voxbone send g729 as preferred codec (18 0 8 101), but this is still not acceptable. I wonder if anybody else seen this bug.

Actions

This Discussion