Other person can't hear me: try port 19305

<< < (3/3)

dlee:
Quote from: Robert.Thompson on March 15, 2012, 06:47:32 am

This is embarrassing but...  :-[

Yesterday, I had the same problem after remotely setting up an OBi 110 from Montreal in Florida: I could call, and hear, Florida but Florida could not hear me. I thought it was a VoIP.ms setting so I chatted back and forth with their support. Couldn't get it to work.

After about an hour of trouble-shooting, I noticed that the microphone on my headset was turned off.

So dlee, is your microphone turned off?

Rob.


No - my microphone was not turned off

dhfobi:
Quote from: QBZappy on March 14, 2012, 09:52:37 pm

dhfobi,

OBi is sending out packets on port 19305. Port forwarding that port to the OBi might be irrelevant, as suggested by the OP, no port forwarding is involved in his solution. However if you read further, Google support site mentions something about Google servers sending packets back to the client to same port. Perhaps making port forwarding relevant after all.

Quote:
"All traffic back to the client from our conference servers will originate from the same port that the client is sending to, and be directed back to the port that the client is sending from."

Looking for info on port 19305 we find references to Google hangout. At first it might seem unrelated to Google voice or GTalk, however it makes references to many of the ports the OP had mentioned.

See: http://support.google.com/a/bin/answer.py?hl=en&answer=1279090

Summary:
The connection methods are attempted in this preferenced order:

1)    A UDP connection from the participant to Google on ports 19305 through 19309
2)    A TCP connection from the participant to Google on ports 19305 through 19309
3)    A TCP connection from the participant to Google on port 80
4)    A TCP connection from the participant to Google on port 443 (SSL)

The ideal connection for a user to make to a hangout is through UDP. To allow this connection attempt to succeed you will need to allow connections into your network from UDP ports 19305 through 19309.

All traffic back to the client from our conference servers will originate from the same port that the client is sending to, and be directed back to the port that the client is sending from.

At a minimum, your corporate network must allow access to the Internet on TCP ports 80 and 443 in order for hangouts to work.

Another site analyzed the TCP connections of Google hangout. An interesting observation in his analysis is there are references that Google hangouts uses GTalk with a destination port 19305.

http://www.coolacid.net/20110701219/Latest/google-hangout-details

Since OBi support mentioned an upcoming firmware fix, port forwarding might not be the cause. I think OBihai just discovered a detail in the GTalk protocol.

QBZappy,
Thanks for researching the OBi port utilization and I have included those ports in my forwarding, but I question the necessity of doing so. Is it really necessary to forward ports to the device when the device has those ports open and is listening on its ip address for packets on those ports? Could the data be lost if not specifically forwarded?  I realize this is not a networking tutorial forum, but the necessity to port forward is not understood by me.

QBZappy:
dhfobi,

Port forwarding is usually required because your router shows a public ip over the public internet (wan), while internally your router may be serving various computers/devices, each requiring it's own different internal ip address.

When an internet service needs to connect to a client computer/device over the internet into your internal network (lan) it is done by pointing to the wan address and by port number. Since the port number can be forwarded to a particular computer/device (ie OBi), the router will know where to deliver those packets.

To go any deeper have a look here:
http://en.wikipedia.org/wiki/Port_forwarding

Stewart:
Quote from: QBZappy on March 14, 2012, 09:52:37 pm

"All traffic back to the client from our conference servers will originate from the same port that the client is sending to, and be directed back to the port that the client is sending from."
If that statement is true in all cases, port forwarding should not be required, except as a workaround for a router bug.  Once the OBi starts sending RTP packets out (to the IP address and port commanded by the Google server), the incoming packets will appear to be replies and should automatically be passed to the OBi.  This is no different from a request from your browser to a web server -- the router sends the reply back to your computer, with no forwarding needed.

dhfobi:
Quote from: Stewart on March 15, 2012, 10:08:37 am

Quote from: QBZappy on March 14, 2012, 09:52:37 pm

"All traffic back to the client from our conference servers will originate from the same port that the client is sending to, and be directed back to the port that the client is sending from."
If that statement is true in all cases, port forwarding should not be required, except as a workaround for a router bug.  Once the OBi starts sending RTP packets out (to the IP address and port commanded by the Google server), the incoming packets will appear to be replies and should automatically be passed to the OBi.  This is no different from a request from your browser to a web server -- the router sends the reply back to your computer, with no forwarding needed.


This is what I thought and in response to QBZappy, the translation he describes is what in my understanding, NAT provides from its routing tables. The port forwarding should only be needed where a firewall is interceding...... I think.

Navigation

[0] Message Index

[*] Previous page