cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
355
Views
0
Helpful
1
Replies

AS5300 falls-back to g711u mysteriously

andrew_pog
Level 1
Level 1

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 Reply 1

andrew_pog
Level 1
Level 1

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.