Re: [bfcpbis] Out-of-sequence or unexpected FloorRequestSatus messages

Thanks for spotting this. I agree that the remaining issue deserves a
portion of text in the spec. It seems to me that acking the unexpected
FloorRequestStatus and recommend that the client issues a
UserQuery/FloorQuery to get in sync in case the Floor Request ID is
not the one known and expected.

I'll raise this issue in the BFCPbis session here at IETF-84 tomorrow.

-- Tom

On 25/07/2012, Horvath, Ernst <ernst.horvath@siemens-enterprise.com> wrote:
> I just noticed that section 6.2 partially covers the issue I described in my
> previous mail. The second last paragraph says:
>
>    "A server-initiated request (e.g. a FloorStatus with an update from
>    the floor control server) received by a participant before the
>    initial FloorRequestStatus message that closes the client-initiated
>    transaction that was instigated by the FloorRequest MUST be treated
>    as superseding the information conveyed in any delinquent response."
>
> However, this does not resolve the problem of the unknown Floor Request ID -
> it may or may not be the one also contained in the late FloorRequestStatus
> that terminates the client-initiaed FloorRequest transaction. If it is the
> same the sentence above is correct, but if it is not then there is some
> state misalignment between server and client that needs sorting out.
>
> Thanks,
> Ernst
>
>> -----Original Message-----
>> From: bfcpbis-bounces@ietf.org
>> [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Horvath, Ernst
>> Sent: Dienstag, 24. Juli 2012 16:40
>> To: bfcpbis@ietf.org
>> Subject: [bfcpbis] Out-of-sequence or unexpected
>> FloorRequestSatus messages
>>
>> A point still missing from the rfc4582bis draft is the
>> handling of an out-of-sequence or unexpected
>> FloorRequestStatus message.
>>
>> An out-of-sequence FloorRequestStatus can occur if a
>> participant has sent a FloorRequest and the first response
>> from the server is lost or overtaken by the next
>> FloorRequestStatus with a different Transaction ID. In this
>> case the client does not yet know the Floor Request ID
>> assigned by the server and cannot determine whether or not
>> the received status message corresponds to the pending FloorRequest.
>>
>> The best way to cope with this situation seems to be that the
>> client ignores any FloorRequestStatus with an unknown Floor
>> Request ID while still waiting for the first response to a
>> FloorRequest the client has sent. Message retransmissions
>> from both sides should eventually sort out the situation. If
>> this is an acceptable solution then corresponding text should
>> be added, e.g. in section 10.1.3.
>>
>> Another situation is the receipt of an unexpected
>> FloorRequestStatus, i.e. one that does not fit any Floor
>> Request ID the client is aware of, and the client has no
>> outstanding FloorRequest transaction waiting for the initial
>> response. Possible reactions could be to respond with
>> FloorRequestStatusAck or to send Goodbye. The client could
>> also try to resynchronise its state information, e.g. via
>> UserQuery or FloorQuery. In any case it seems worthwhile to
>> cover this situation in the draft, too.
>>
>> BTW, the other "subscription-like" message pair, FloorQuery
>> and FloorStatus, shouldn't have this problem.
>>
>> Regards,
>> Ernst
>>
>> _______________________________________________
>> bfcpbis mailing list
>> bfcpbis@ietf.org
>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis
>

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## tomkrist@cisco.com  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/