[cisco-voip] IOS and RFC 3556 support

[Andreas Sikkema]

Hi,

We have a couple of Cisco IOS based VoIP machines (AS5350XM ISDN30
gateways and 2801 CUBEs) and when they receive a call containing
specific RFC 3556 information in the SDP calls are rejected.

The only reference to RFC 3556 I can find on the Cisco site is related
to the SBC functionality on an ASR1000
(http://www.cisco.com/en/US/docs/routers/asr1000/configuration/guide/sbcu/sbc_sdpbw.html)
but that doesn't mention the specific fields I am having problems
with.

Here's an example of a message received by the Cisco machines
containing the fields:

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP xxxxxxxx:5060;branch=z9hG4bK4c35.5b48e4b.0
Via: SIP/2.0/UDP
xxxx:5060;received=xxxxx;rport=62955;x-route-tag="cid:blah";branch=z9hG4bK2D3293314D4
From: <sip:0xxxxxxxxx at xxxxxxxx>;tag=518D974C-198D
To: <sip:0xxxxxxx at xxxxxxx>;tag=SDcaa1899-227626126866920131113103043
Call-ID: xxxx at yyyyy
CSeq: 101 INVITE
Record-Route: <sip:xxxxxxxxx;lr;ftag=518D974C-198D;did=1f4.fdba577>
Require: 100rel
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK,UPDATE
RSeq: 913
Contact: <sip:+31xxxxxxxx at xxxxxxxxxx:5060;transport=udp>
Supported: 100rel
Content-Type: application/sdp
Content-Length: 258

v=0
o=- 13549184 13549184 IN IP4 xxxxxxxx
s=-
c=IN IP4 xxxxxxxx
t=0 0
a=sendrecv
m=audio 49980 RTP/AVP 8 101
c=IN IP4 xxxxxxxxx
b=RR:0
b=RS:0
a=rtpmap:8 PCMA/8000
a=maxptime:40
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

The problem are the b=RR:0 and b=RS:0 fields.

I've tried removing them using a sip profile on the correct dial-peer:

voice class sip-profiles 200
 request ANY sdp-header Audio-Bandwidth-Info remove
 response ANY sdp-header Audio-Bandwidth-Info remove
 request ANY sdp-header Video-Bandwidth-Info remove
 response ANY sdp-header Video-Bandwidth-Info remove
 request ANY sdp-header Bandwidth-Key remove
 response ANY sdp-header Bandwidth-Key remove

I am seeing the profile being used when doing a test call and having
debug enabled, but the behaviour doesn't change and one of the
bandwidth lines is not being hit.

Has anyone seen this before? I can try to remove the fields elsewhere
in our platform, but that would mean spending loads of CPU cycles in
places where just a part of the calls really need this fix. I'd rather
fix this at the source of the problem.

Has anyone seen this before and fixed it?

-- 
Andreas Sikkema