Hello everybody, I am new to this list and have just a simple question: We are using an Sierre Wireless Raven XT router to send data from a remote place to our servers And at the moment the connection is not fully established (we cannot connect with Loggernet Campbell Scientic Program). A port scan from the machine gives: PORT STATE SERVICE 1720/tcp open H.323/Q.931 Which is the only open port (no SSH, no HTML Port). Is there a possibility to get through this port to change the configuration of the router? Any help would be appreciated. Best regards, Christian Braun Christian Braun | System Development Concentrix Solar GmbH | Bötzinger Str. 31 | 79111 Freiburg | Germany T +49 761 214 108 35 | F +49 761 214 108 29 | M +49 1522 273 66 35 christian.braun@concentrix-solar.de<mailto:christian.braun@concentrix-solar.de> | www.concentrix-solar.de<http://www.concentrix-solar.de/> Managing Directors: Hansjörg Lerchenmüller, Emmanuel Arène | Chairman of the Board: Dr. André-Jacques Auberton-Hervé HRB 7492 Register Court Freiburg | Disclaimer: www.concentrix-solar.de/disclaimer<http://www.concentrix-solar.de/disclaimer> Concentrix Solar is a division of the Soitec Group: www.soitec.com<http://www.soitec.com/>
Christian TCP 1720 is used for H.323 call signaling and is only used during a video conferencing call. The device maybe using port 1720 but it may not be video conferencing related unless there is a video conferencing device behind the router connect to a device outside the router and you certainly cannot configure the router on that port. Simon From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Braun, Christian Sent: Friday, January 07, 2011 11:49 PM To: h323plus@lists.packetizer.com Subject: [h323plus] Possible Entry through h.323 at Port 1720 Hello everybody, I am new to this list and have just a simple question: We are using an Sierre Wireless Raven XT router to send data from a remote place to our servers And at the moment the connection is not fully established (we cannot connect with Loggernet Campbell Scientic Program). A port scan from the machine gives: PORT STATE SERVICE 1720/tcp open H.323/Q.931 Which is the only open port (no SSH, no HTML Port). Is there a possibility to get through this port to change the configuration of the router? Any help would be appreciated. Best regards, Christian Braun Christian Braun | System Development Concentrix Solar GmbH | Bötzinger Str. 31 | 79111 Freiburg | Germany T +49 761 214 108 35 | F +49 761 214 108 29 | M +49 1522 273 66 35 christian.braun@concentrix-solar.de <mailto:christian.braun@concentrix-solar.de> | www.concentrix-solar.de <http://www.concentrix-solar.de/> Managing Directors: Hansjörg Lerchenmüller, Emmanuel Arène | Chairman of the Board: Dr. André-Jacques Auberton-Hervé HRB 7492 Register Court Freiburg | Disclaimer: www.concentrix-solar.de/disclaimer Concentrix Solar is a division of the Soitec Group: www.soitec.com <http://www.soitec.com/>
[H.261] The H.261 VIC codec does not work with hardware devices like Polycom's. The device complains about invalid sbit/ebit values. The codec resets the sbit to 0 on a new picture, introducing an apparent discontinuity in the bitstream. However the device expects the bitstream to be continuos (prev.ebit + this.sbit = 8). The fix is quite simple: just comment out H261PixelEncoder::PreIncEncodeSetup() { ... sbit_ = 0; ... } in "opal\plugins\video\H.261-vic\vic\encoder-h261.cxx". [G.722] The G.722 codec is never initialized. The codec reports a format of "PCM-16-16kHz" (L16Desc[] in "opal\plugins\audio\G722\g722codec.c") while the plugin manager only accepts "L16" (H323PluginCodecManager::RegisterCodecs() in "h323plus\src\h323pluginmgr.cxx"). Shouldn't the codec report "L16" in the 8 kHz descriptor? Or is there a deeper issue? Replacing "PCM-16-16kHz" with "L16" enables the decoder but not the encoder and the decoder doesn't decode anything. G.722.2 seems to have the same issue. -- Alessandro
Thanks Alessandro I have made the change to H.261 plugin please check if it ok. I have also checked into the CVS a working G.722.1(16k) codec. The G.722.1c (32k) is commented out for now as it has not been properly tested. You are welcome to test it and report back. Simon -----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Alessandro Angeli Sent: Saturday, January 08, 2011 8:20 AM To: h323plus@lists.packetizer.com Subject: [h323plus] H.261 and G.722 [H.261] The H.261 VIC codec does not work with hardware devices like Polycom's. The device complains about invalid sbit/ebit values. The codec resets the sbit to 0 on a new picture, introducing an apparent discontinuity in the bitstream. However the device expects the bitstream to be continuos (prev.ebit + this.sbit = 8). The fix is quite simple: just comment out H261PixelEncoder::PreIncEncodeSetup() { ... sbit_ = 0; ... } in "opal\plugins\video\H.261-vic\vic\encoder-h261.cxx". [G.722] The G.722 codec is never initialized. The codec reports a format of "PCM-16-16kHz" (L16Desc[] in "opal\plugins\audio\G722\g722codec.c") while the plugin manager only accepts "L16" (H323PluginCodecManager::RegisterCodecs() in "h323plus\src\h323pluginmgr.cxx"). Shouldn't the codec report "L16" in the 8 kHz descriptor? Or is there a deeper issue? Replacing "PCM-16-16kHz" with "L16" enables the decoder but not the encoder and the decoder doesn't decode anything. G.722.2 seems to have the same issue. -- Alessandro
Simon, after your change to the H.261 plugin, it stopped working for me: With the new plugin, I only receive a black video stream with Spranto and Polycom PVX. I had tested the old plugin with Polycom PVX, Polycom HDX 9004, Tandberg T3 and the Mirial Softphone and all worked. Alessandro, which Polycom device causes you trouble ? Is the new plugin working any better there ? I would suggest to revert that patch for now. Regards, Jan Simon Horne wrote:
Thanks Alessandro
I have made the change to H.261 plugin please check if it ok.
I have also checked into the CVS a working G.722.1(16k) codec. The G.722.1c (32k) is commented out for now as it has not been properly tested. You are welcome to test it and report back.
Simon
-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Alessandro Angeli Sent: Saturday, January 08, 2011 8:20 AM To: h323plus@lists.packetizer.com Subject: [h323plus] H.261 and G.722
[H.261] The H.261 VIC codec does not work with hardware devices like Polycom's. The device complains about invalid sbit/ebit values.
The codec resets the sbit to 0 on a new picture, introducing an apparent discontinuity in the bitstream. However the device expects the bitstream to be continuos (prev.ebit + this.sbit = 8).
The fix is quite simple: just comment out H261PixelEncoder::PreIncEncodeSetup() { ... sbit_ = 0; ... } in "opal\plugins\video\H.261-vic\vic\encoder-h261.cxx".
[G.722] The G.722 codec is never initialized. The codec reports a format of "PCM-16-16kHz" (L16Desc[] in "opal\plugins\audio\G722\g722codec.c") while the plugin manager only accepts "L16" (H323PluginCodecManager::RegisterCodecs() in "h323plus\src\h323pluginmgr.cxx").
Shouldn't the codec report "L16" in the 8 kHz descriptor? Or is there a deeper issue? Replacing "PCM-16-16kHz" with "L16" enables the decoder but not the encoder and the decoder doesn't decode anything.
G.722.2 seems to have the same issue.
-- Alessandro
-- Jan Willamowius, jan@willamowius.de, http://www.gnugk.org/
From: "Jan Willamowius" <jan@willamowius.de> Date: Monday 10 January 2011 04:30
after your change to the H.261 plugin, it stopped working for me: With the new plugin, I only receive a black video stream with Spranto and Polycom PVX.
I had tested the old plugin with Polycom PVX, Polycom HDX 9004, Tandberg T3 and the Mirial Softphone and all worked.
Alessandro, which Polycom device causes you trouble ? Is the new plugin working any better there ?
So far only the Polycom VSX 5000: it was the first one I tried and it did not work, so I found a fix for it but have not tested it with other devices yet. In any case the fix makes sense: resetting the sbit to 0 produces a packet stream that is RFC2032-compliant but the resulting bitstream is not H.261-compliant, that is it is decodable only by an RFC-aware decoder. However H261Encoder::sbit_ seems to never be initialized to a know value, so it is possible that (depending on machine, build type and alignment of the Moon in Pisces) the initial value falls outside the 0..7 range and nothing will work. Can you try to add , sbit_(0) (including the leading comma) to the list of initializers of H261Encoder::H261Encoder() (the very first function defined in encoder-h261.cxx)? -- Alessandro
Simon took out the whole call to PreIncEncodeSetup() and not just the zeroing of sbit_. I have restored that and added the initialization of sbit_ in the H261Encode c'tor. Unfortuantely it doesn't help - if sbit_ isn't reset to 0, the plugin crashes in InEncodeAndGetPacket(), so I just commented the suggested removal for now. Alessandro, could you please provide a "diff -u" of your code against the latest CVS ? Thanks, Jan Alessandro Angeli wrote:
From: "Jan Willamowius" <jan@willamowius.de> Date: Monday 10 January 2011 04:30
after your change to the H.261 plugin, it stopped working for me: With the new plugin, I only receive a black video stream with Spranto and Polycom PVX.
I had tested the old plugin with Polycom PVX, Polycom HDX 9004, Tandberg T3 and the Mirial Softphone and all worked.
Alessandro, which Polycom device causes you trouble ? Is the new plugin working any better there ?
So far only the Polycom VSX 5000: it was the first one I tried and it did not work, so I found a fix for it but have not tested it with other devices yet.
In any case the fix makes sense: resetting the sbit to 0 produces a packet stream that is RFC2032-compliant but the resulting bitstream is not H.261-compliant, that is it is decodable only by an RFC-aware decoder.
However H261Encoder::sbit_ seems to never be initialized to a know value, so it is possible that (depending on machine, build type and alignment of the Moon in Pisces) the initial value falls outside the 0..7 range and nothing will work.
Can you try to add
, sbit_(0)
(including the leading comma) to the list of initializers of H261Encoder::H261Encoder() (the very first function defined in encoder-h261.cxx)?
-- Alessandro
-- Jan Willamowius, jan@willamowius.de, http://www.gnugk.org/
From: "Jan Willamowius" <jan@willamowius.de> Date: Monday 10 January 2011 16:47
Simon took out the whole call to PreIncEncodeSetup() and not just the zeroing of sbit_. I have restored that and added the initialization of sbit_ in the H261Encode c'tor. Unfortuantely it doesn't help - if sbit_ isn't reset to 0, the plugin crashes in InEncodeAndGetPacket(), so I just commented the suggested removal for now.
Alessandro, could you please provide a "diff -u" of your code against the latest CVS ?
The only modifications are the commenting out of sbit_ = 0; (Simon delete the line instead, but not the whole function) and the added the initialization of sbit_(0). Here is the diff: Index: opal/plugins/video/H.261-vic/vic/encoder-h261.cxx =================================================================== --- opal/plugins/video/H.261-vic/vic/encoder-h261.cxx (revision 24864) +++ opal/plugins/video/H.261-vic/vic/encoder-h261.cxx (working copy) @@ -127,6 +127,7 @@ H261Encoder::H261Encoder(Transmitter *T) : Encoder(T), bs_(0), bc_(0), ngob_(12), gDone(true) // must initialize to true + , sbit_(0) { for (int q = 0; q < 32; ++q) { llm_[q] = 0; @@ -798,7 +799,7 @@ bc_ = gData; //where to put encoded bits gStep = cif_ ? 1 : 2; //Macro Block step size gGobMax = cif_ ? 12 : 5; //how many GOB per frame - sbit_ = 0; + // sbit_ = 0; gSendGOBhdr = true; //must send GOB hdr before sending MB gGOBhdrNxt = true; //will start out with GOB header //because gGOBhdrNxt == true, no need to initialize the following 2 header variables: -- Alessandro
Alessandro, you are looking at the OPAL SVN, not the H323Plus CVS. That might explain why things behave slightly different... Regards, Jan Alessandro Angeli wrote:
From: "Jan Willamowius" <jan@willamowius.de> Date: Monday 10 January 2011 16:47
Simon took out the whole call to PreIncEncodeSetup() and not just the zeroing of sbit_. I have restored that and added the initialization of sbit_ in the H261Encode c'tor. Unfortuantely it doesn't help - if sbit_ isn't reset to 0, the plugin crashes in InEncodeAndGetPacket(), so I just commented the suggested removal for now.
Alessandro, could you please provide a "diff -u" of your code against the latest CVS ?
The only modifications are the commenting out of sbit_ = 0; (Simon delete the line instead, but not the whole function) and the added the initialization of sbit_(0).
Here is the diff:
Index: opal/plugins/video/H.261-vic/vic/encoder-h261.cxx =================================================================== --- opal/plugins/video/H.261-vic/vic/encoder-h261.cxx (revision 24864) +++ opal/plugins/video/H.261-vic/vic/encoder-h261.cxx (working copy) @@ -127,6 +127,7 @@ H261Encoder::H261Encoder(Transmitter *T) : Encoder(T), bs_(0), bc_(0), ngob_(12), gDone(true) // must initialize to true + , sbit_(0) { for (int q = 0; q < 32; ++q) { llm_[q] = 0; @@ -798,7 +799,7 @@ bc_ = gData; //where to put encoded bits gStep = cif_ ? 1 : 2; //Macro Block step size gGobMax = cif_ ? 12 : 5; //how many GOB per frame - sbit_ = 0; + // sbit_ = 0; gSendGOBhdr = true; //must send GOB hdr before sending MB gGOBhdrNxt = true; //will start out with GOB header //because gGOBhdrNxt == true, no need to initialize the following 2 header variables:
-- Alessandro
-- Jan Willamowius, jan@willamowius.de, http://www.gnugk.org/
From: "Jan Willamowius" <jan@willamowius.de> Date: Monday 10 January 2011 17:51
you are looking at the OPAL SVN, not the H323Plus CVS. That might explain why things behave slightly different...
I tried the h323plus code (Revision 1.2 2011/01/10 21:42:24) with the same result. The Polycom VSX 5000 only accepts the video if sbit_ = 0 is commented out in line 807 of encoder-h261.cxx. If you get rev 1.2 (latest) and comment out that line, does it not work for you? Notice that the video may take several secs to start on the device side, but I do not think that is related to this change. -- Alessandro
participants (4)
-
Alessandro Angeli -
Braun, Christian -
Jan Willamowius -
Simon Horne