Traversing Firewalls or Network Address Translation Devices

[CosbyBs86]

From GigEVision Standard 2.0.03: 11.9 Traversing Firewalls or Network Address Translation Devices Due to the unidirectional nature of GVSP traffic, it is common for the streaming channel data to be blocked by firewalls or other types of network since the incoming traffic cannot be matched against an outgoing packet. To address this, the SCSPx registers are designed to allow the application associated to a GVSP receiver to create a simulated bidirectional traffic conversation between the GVSP receiver and the GVSP transmitter streaming channel by informing the application of the remote UDP port. This information would otherwise be unknown until the first streaming packet arrives, which may never happen if it was blocked. Additionally, this information may be used in other ways to help configure software and/or networking equipment. The GVSP Capability register (at address 0x092C) can be used to query if SCSPx registers are supported by this device. [CR-094st] If a product supports SCSPx for one GVSP transmitter, then it MUST support it for all its GVCP transmitter stream channels. [CR10-8st] The suggested usage of SCSPx is to query it after opening the image stream via SCDAx and SCPx but before starting the camera’s flow of image data. If desired, the application can query it earlier and cache it off (only if it is non-zero) so that it does not need to query it each time the streaming channel is opened. Refer to [CR-089cd] for proper behavior of SCSPx. Next, the application can send a UDP packet from the same source port it programmed into SCPx to the port specified by SCSPx. The content of this packet is ignored, but the suggested payload should be smaller than the maximum size of a GVCP command packet. This operation should be realized on all the open stream channels. GigE Vision® Specification version 2.0 V2.0.03 April 16, 2013 Page 92 of 427 At this point the application can continue starting the acquisition on the camera. Depending on the configuration of the firewall or other impediment, the application may choose to continue periodically sending packets similar to the first one for the duration of the streaming session. The suggested interval is 30 seconds and could be configurable. Different firewalls might require adjustment to this interval. [CR-095ca] When SCSPx is supported by the application, the application MUST not send packets to the port specified by SCSPx unless it has the stream channel opened and successfully reads a non-zero value back from SCSPx. [CR10-9ca] The application should not expect the device to answer the packet it sends to the GVSP transmitter stream channel. But this mechanism provides a way to open-up the UDP port in the firewall. The implementation is left as a quality of implementation and is likely to vary with different firewall types and operating systems. Note that the same mechanism is also available for the message channel.

[CosbyBs86]

@Touseefelahi I had the chance to test it with my company laptop and it looks like it is making its job. At the moment I didn't introduce the 30secs loop but it sends the package when the receiver is started. Probably sending the package during the stream is not needed

[Touseefelahi]

@CosbyBs86 It usually doesn't need to be sent continuously. The issue typically arises at the beginning of the stream, but once the stream is running, it functions correctly.

[CosbyBs86]

@CosbyBs86 It usually doesn't need to be sent continuously. The issue typically arises at the beginning of the stream, but once the stream is running, it functions correctly.

I do agree with you. I think this implementation is fine then.

[Touseefelahi]

Did you test it with and without this implementation on your laptop. Logically, the stream should not work without this implementation.

[CosbyBs86]

Did you test it with and without this implementation on your laptop. Logically, the stream should not work without this implementation.

exactly without the implementation I've been blocked by the firewall. with my change it worked

[Touseefelahi]

@CosbyBs86 perfect! thank you for your support

[CosbyBs86]

@Touseefelahi no problem. I found a small issue on the management of enum parameters when they are registry addresses rather then integer. I'm fixing it and I'll send you the PR today

[Touseefelahi]

@CosbyBs86 I guess the 30 seconds loop is also supposed to be added, because as mentioned in the standard it depends on the firewall, so maybe the stream will stop for some of the firewalls.

[CosbyBs86]

@CosbyBs86 I guess the 30 seconds loop is also supposed to be added, because as mentioned in the standard it depends on the firewall, so maybe the stream will stop for some of the firewalls.

I have the idea where to implement it. I'll send you the fix for enum then i'll have a look on the loop. Maybe in my lunch break :)