[cisco-voip] IOS and RFC 3556 support

[Brian Meade (brmeade)]

Also if this is incoming, this issue was resolved in CSCtb74536- http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtb74536

Brian

-----Original Message-----
From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Brian Meade (brmeade)
Sent: Thursday, November 14, 2013 9:23 AM
To: Andreas Sikkema; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] IOS and RFC 3556 support

Where do you have the SIP Profile applied?  Is that an Incoming 183 Session Progress?  Right now, CUBE can only modify outgoing messages with SIP-profiles.

Brian

-----Original Message-----
From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Andreas Sikkema
Sent: Thursday, November 14, 2013 9:16 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] IOS and RFC 3556 support

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
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip