cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
1309
Views
0
Helpful
3
Replies
Wayne_G
Beginner

BFCP issue with CUCM & VCS to 3rd party

Hi All,

 

Just throwing this question out to the community as TAC have been less than helpful in resolving our issue, have a case open for 2 months now with no progress.

 

We have an issue where BFCP presentation does not always work between our Cisco codecs (SX20, SX80, C40) and external 3rd party SIP devices. When presentation is initiated from the 3rd party no content is received, and when presentation is initiated from us the content is received in the main video channel. Therefore BFCP negotiation has failed.

 

Our endpoints are registered to a CUCM cluster running 11.5.1 and external SIP video calls traverse a pair of expressway C & E clusters running 8.10.4. I thought this was working before we upgraded from CUCM 10.6 late last year but I could be wrong.

 

I have been able to narrow down the difference between a working and non working call. In the SIP invite message, our endpoints send floorctrl capability of c-s (client and server). Presentation works fine when the 3rd party answers with either c-only or s-only. But when the 3rd party answers with c-s, presentation fails. I can see from sdl traces that Call Manager modifies the answer from c-s to c-only. When the 3rd party begins sending content the Cisco endpoint ignores it and logs this message:

 

Bfcp W: handleFloorStatus: Server session. Ignoring floor status from a.b.c.d:39770

 

If I register the endpoint directly to Exp-C instead of CUCM and make the same call to a non working external 3rd party, the floorctrl answer attribute is "s-only" and presentation works as expected.

 

TAC has siad that modifying the offer from 'c-s' to 'c-only' is by design and provided the following blurp from a Cisco whitepaper (EDCS-872563):

 

Note: As per RFC 4583, an offer with ‘c-s’ must be answered with 'c-s'. This restricts the interworking between endpoints that can either act as c-only or s-only. Therefore, should an offer to contain only ‘c-s’, UCM will treat it as c-only and s-only. Though this may appear to be a deviation from RFC 4583, it allow interoperability with endpoints that can take the role c-only or s-only.

 

From what they are saying, CUCM has always behaved this way, not just in 11.5. Why not do the same in Expressway/VCS if they believe it will increase interoperability? Since it is working when CUCM is out of the call flow, it would seem the endpoints can handle the negotiation better themselves.

 

Has anyone else run into this issue?

3 REPLIES 3
Wayne_G
Beginner

Appears to be resolved. After this case was finally escalated, another engineer suggested to try changing the 'Media encryption mode' setting on the CUCM neighbor zone from 'Auto' to 'Force unencrypted'. I am now just waiting for an explanation as to why this would make a difference, when the transport is set to TCP anyway (not TLS).

If this solves my problem tomorrow I will be beyond thrilled . I have been having this problem with Jabber and Webex where sharing randomly works properly . Turning video on and off changes it - very bizarre. 

 

Encryption isn’t transport - refers to the media content in the transport stream. I have to set this to anything other than force encrypted to talk to Webex as the B2BUA won’t encrypt the media, or the calls fail. 

 

 

Ah thanks for clarifying that for me. Hope you're able to solve your issue too.

Content for Community-Ad

Spotlight Awards 2021