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?
