Stopping a stream from unknown source

[gspreeth]

Hi, I have a scenario where I start a stream between two devices. Now I close down the controller and remove one of the devices from the network. When running the controller again the remaining device will still report an active stream but as we do not have the other end point available the normal disconnect command cannot be used. Is there any way to force the device to remove the connection from itself or disconnect a "one sided" connection..

Thank you in advance..

[andrew-elder]

On 1/22/2015 7:07 AM, gspreeth wrote:

Hi, I have a scenario where I start a stream between two devices. Now I
close down the controller and remove one of the devices from the network.
When running the controller again the remaining device will still report
an active stream but as we do not have the other end point available the
normal disconnect command cannot be used. Is there any way to force the
device to remove the connection from itself or disconnect a "one sided"
connection..

Thank you in advance..

—
Reply to this email directly or view it on GitHub
#175.

Did you remove the talker or the listener?

Andrew Elder
AudioScience, Inc.
+1-585-271-8870
www.audioscience.com

[gspreeth]

You can remove either. The remaining talker or listener will report stream the same as if the other one was still there.

[andrew-elder]

If the listener is still on the network, you can send an ACMP DISCONNECT command. This may be an endstation issue rather than a controller issue.

[gspreeth]

I am testing with a mix of devices, but with a 2Ch devboard from XMOS a listener reports the following:
stream_id = 0x22970405590000
talker_unique_id = 0
listener_unique_id = 0
stream_dest_mac = 0x91e0f0009f98
connection_count = 1
flags = 0
stream_vlan_id = 2

This is the only board on the network, the talker was disconnected.
I then try to send a ACMP DISCONNECT command with the controller by using the send_disconnect_rx_cmd

COMMAND_SENT, 0x2297fffe0043d1, DISCONNECT_RX_COMMAND, NULL, NULL, SUCCESS, 1 0

I get a not connected response back and nothing changes.

RESPONSE_RECEIVED, 0x2297fffe0043d1, DISCONNECT_RX_RESPONSE, NULL, NULL, NOT_CONNECTED, 1 0

Any idea where I am going wrong with this?

Thanks a lot.

[jdkoftinoff]

A listener that receives the ACMP DISCONNECT_RX_COMMAND message from a Controller is required to execute the state machine described in IEEE Std 1722.1-2013 Clause 8.2.2.5.3

The Listener would go into DISCONNECT_RX_COMMAND State which says:

if(validListenerUnique(rcvdCmdResp.listener_unique_id))
{
if(listenerIsConnectedTo(rcvdCmdResp))
{
(response, status) = disconnectListener(rcvdCmdResp);
if(SUCCESS == status)
{
txCommand(DISCONNECT_TX_COMMAND, rcvdCmdResp, FALSE);
}
else
{
txResponse(DISCONNECT_RX_RESPONSE, response, status);
}
}
else
{
txResponse(DISCONNECT_RX_RESPONSE, rcvdCmdResp, NOT_CONNECTED);
}
}
else
{
txResponse(DISCONNECT_RX_RESPONSE, rcvdCmdResp, LISTENER_UNKNOWN_ID);
}

This means that your connection count on the listener side should have been decreased.

AFTER that, the listener sends the ACMP DISCONNECT_TX_COMMAND message to the talker.
If the Talker does not respond, the listener would enter the DISCONNECT_TX_TIMEOUT state which says to do the following:

f(inflight[x].retried)
{
response = inflight[x].command;
response.sequence_id = inflight[x].original_sequence_id;
txResponse(DISCONNECT_RX_RESPONSE, response, LISTENER_TALKER_TIMEOUT);
removeInflight(inflight[x].command);
}
else
{
txCommand(DISCONNECT_TX_COMMAND, inflight[x].command, TRUE);
}

which basically says that there could be a LISTENER_TALKER_TIMEOUT error coming back to the controller.

So it is clear that the listener that you are sending the command to does not have the correct ACMP Listener State machine programmed.

Regards,
Jeff

On Jan 22, 2015, at 07:39, gspreeth [email protected] wrote:

I am testing with a mix of devices, but with a 2Ch devboard from XMOS a listener reports the following:
stream_id = 0x22970405590000
talker_unique_id = 0
listener_unique_id = 0
stream_dest_mac = 0x91e0f0009f98
connection_count = 1
flags = 0
stream_vlan_id = 2

This is the only board on the network, the talker was disconnected.
I then try to send a ACMP DISCONNECT command with the controller by using the send_disconnect_rx_cmd

COMMAND_SENT, 0x2297fffe0043d1, DISCONNECT_RX_COMMAND, NULL, NULL, SUCCESS, 1 0

I get a not connected response back and nothing changes.

RESPONSE_RECEIVED, 0x2297fffe0043d1, DISCONNECT_RX_RESPONSE, NULL, NULL, NOT_CONNECTED, 1 0

Any idea where I am going wrong with this?

Thanks a lot.

—
Reply to this email directly or view it on GitHub #175 (comment).

[gspreeth]

Thanks for the help!
After some testing it seems that all devices from different manufacturers I have tested does in fact handle this wrong. The listener sends ACMP DISCONNECT_TX_COMMAND to the talker. and only after a successful response from the talker does it decrease its connection count. In some cases a stream disabled state is set but connection not erased (because of talker timeout) and after the first attempt you only get a NOT_CONNECTED response for subsequent requests. I will take this up with the relevant vendors..