Hi Luiz, Thank you for the review, let me better explain the flow that I proposed, because I think I should have added a more detailed description to this patch. I added the num_bis field to the QoS structure so that the user can specify from the start the total number of connections that will be opened for the BIG, but one socket will always be connected to an unique BIS. So the user will first open a socket, set the QoS options with the num_bis parameter set to the number of BISes, and then the user will call connect on that socket. The BIG will be created with the specified number of BISes, but the socket will only be connected to one of them. The rest of the connection handles will be stored in the "bigs" queue that I added. Later on, the user might decide to open new sockets, for the rest of the BISes that are created and stored in the queue. In this case, the connect API on the socket will not issue the LE Create BIG command again, but it will extract a connection handle from the queue and the socket will be connected instantly. As for the HCI_CONN_PER_ADV flag, I noticed that it was only checked in the "bis_cleanup" function, to decide whether the advertising set and the BIG should be terminated. I removed it because now I am only terminating the advertising set and the BIG if all of the BIS handles have been assigned and no other BISes are in the BT_CONNECTED state for that BIG, so I thought I might not need the flag anymore. I think it's a better idea to use DEFER_SETUP for binding multiple BISes to a BIG, instead of using the num_bis QoS parameter, so that I can keep each socket completely separated from information about other connections, so I will update the implementation. Regards, Iulia
