News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Other person can't hear me: try port 19305

Started by dlee, March 14, 2012, 02:04:37 PM

Previous topic - Next topic

dlee

Today, all my calls using Obi110 (via Google Voice), the other person could not hear me. After researching my router's log, etc., the Obi110 was sending packets to port 19305. So, I added this to my QoS rules and it solved the problem. Hope this helps you.

My configuration details below:
Router: NNR3500L
firmware: Tomato Firmware v1.28.7495 MIPSR2-Toastman-RT K26 USB VPN
Port Foward: TCP & UDP, Port 10000, to Obi110 IP address
QoS:
TCP/UDP
Port: 5060-5063,3478,3479   VOIP/Game   SIP, Sipgate Stun Services   5
TCP/UDP
Port: 16600-16998,10000,6800   VOIP/Game   Obi110 RTP and Obi110 Out   6
TCP/UDP
Port: 5222,5223,19305,5269,4893,19294,19295,19302   VOIP/Game   Google Talk Full Voice and Video   7

dhfobi

Quote from: dlee on March 14, 2012, 02:04:37 PM
Today, all my calls using Obi110 (via Google Voice), the other person could not hear me. After researching my router's log, etc., the Obi110 was sending packets to port 19305. So, I added this to my QoS rules and it solved the problem. Hope this helps you.

My configuration details below:
Router: NWR3500L
firmware: Tomato Firmware v1.28.7495 MIPSR2-Toastman-RT K26 USB VPN
Port Foward: TCP & UDP, Port 10000, to Obi110 IP address
QoS:
TCP/UDP
Port: 5060-5063,3478,3479   VOIP/Game   SIP, Sipgate Stun Services   5
TCP/UDP
Port: 16600-16998,10000,6800   VOIP/Game   Obi110 RTP and Obi110 Out   6
TCP/UDP
Port: 5222,5223,19305,5269,4893,19294,19295,19302   VOIP/Game   Google Talk Full Voice and Video   7

Very interesting, I wonder if one of the OBi Gurus would comment on the use of port 19305 ( I assume your use of 19302 above is a typo )
I have port forwarded the 16600-16998 range to my Obi100, and had never heard mentioned the OBi use of 19305. Are there any others in use we should be aware of?
Also having forwarded those ports to my OBi100 and having it in the highest QoS priority, is it necessary to also prioritize the ports in QoS? That sounds redundant.
I will port forward 19305 as well now that you have found it solves your(our) problem but I wonder if what we're doing is meaningful or that it was just a coincidence since the problem doesn't occur all the time, however the fact that you saw Obi using 19305 indicates that it can't hurt to make sure it can always have priority use.
Any comments from Obi tech support would be welcomed.

QBZappy

I use Tomoto USB Teddy Bear version. I think if you prioritize the Mac address of the OBi, it should pass any port used by the OBi, as highest priority if set that way. A different approach as opposed to picking a port one by one.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

dhfobi

Quote from: QBZappy on March 14, 2012, 03:44:58 PM
I use Tomoto USB Teddy Bear version. I think if you prioritize the Mac address of the OBi, it should pass any port used by the OBi, as highest priority if set that way. A different approach as opposed to picking a port one by one.
Yes, that's what I thought as well, and I have prioritized the OBi Mac address from the beginning, so I guess port 19305 should be already prioritized even if not separately port forwarded.

dlee

Quote from: dhfobi on March 14, 2012, 03:33:55 PM
Quote from: dlee on March 14, 2012, 02:04:37 PM
Today, all my calls using Obi110 (via Google Voice), the other person could not hear me. After researching my router's log, etc., the Obi110 was sending packets to port 19305. So, I added this to my QoS rules and it solved the problem. Hope this helps you.

My configuration details below:
Router: NWR3500L
firmware: Tomato Firmware v1.28.7495 MIPSR2-Toastman-RT K26 USB VPN
Port Foward: TCP & UDP, Port 10000, to Obi110 IP address
QoS:
TCP/UDP
Port: 5060-5063,3478,3479   VOIP/Game   SIP, Sipgate Stun Services   5
TCP/UDP
Port: 16600-16998,10000,6800   VOIP/Game   Obi110 RTP and Obi110 Out   6
TCP/UDP
Port: 5222,5223,19305,5269,4893,19294,19295,19302   VOIP/Game   Google Talk Full Voice and Video   7

Very interesting, I wonder if one of the OBi Gurus would comment on the use of port 19305 ( I assume your use of 19302 above is a typo )
I have port forwarded the 16600-16998 range to my Obi100, and had never heard mentioned the OBi use of 19305. Are there any others in use we should be aware of?
Also having forwarded those ports to my OBi100 and having it in the highest QoS priority, is it necessary to also prioritize the ports in QoS? That sounds redundant.
I will port forward 19305 as well now that you have found it solves your(our) problem but I wonder if what we're doing is meaningful or that it was just a coincidence since the problem doesn't occur all the time, however the fact that you saw Obi using 19305 indicates that it can't hurt to make sure it can always have priority use.
Any comments from Obi tech support would be welcomed.

I only noticed port 19305 today since on all my calls no one on the other end can hear me. And, rebooting and unplugging the router and Obi110 did not help - did this several times.

The ports I listed for Google Talk are from my Internet searches. Port 19302 is not a mistake.

I debated on whether to just prioritize by IP or by Ports -- in the end, I choose ports since we have 3 kids and everyone is downloading, videoing, P2P, etc.

dhfobi

Considering that we don't know all of the ports OBi is or might be using in the future, I think the idea of setting a static ip for the device and prioritizing the device by its mac address in QoS, as the highest priority,which is what QBZappy and I are doing, should prioritze any and all port usage now and into the future, rather than try to keep a vigil on port usage and update port fowarding when new ports are detected.

If this is an incorrect assumption please let me know, anyone, thanks

RonR

Quote from: dhfobi on March 14, 2012, 06:16:40 PM
Considering that we don't know all of the ports OBi is or might be using in the future, I think the idea of setting a static ip for the device and prioritizing the device by its mac address in QoS, as the highest priority,which is what QBZappy and I are doing, should prioritze any and all port usage now and into the future, rather than try to keep a vigil on port usage and update port fowarding when new ports are detected.

If this is an incorrect assumption please let me know, anyone, thanks

I don't believe that port forwarding and QoS are in any way related.  IOW, QoS doesn't open/forward any ports.

dhfobi

Quote from: RonR on March 14, 2012, 07:09:07 PM
Quote from: dhfobi on March 14, 2012, 06:16:40 PM
Considering that we don't know all of the ports OBi is or might be using in the future, I think the idea of setting a static ip for the device and prioritizing the device by its mac address in QoS, as the highest priority,which is what QBZappy and I are doing, should prioritze any and all port usage now and into the future, rather than try to keep a vigil on port usage and update port fowarding when new ports are detected.

If this is an incorrect assumption please let me know, anyone, thanks

I don't believe that port forwarding and QoS are in any way related.  IOW, QoS doesn't open/forward any ports.

OK, if that's the case I'll add the listed ports to port forwarding to my OBi100, may not be necessary but it can't hurt.
Thanks

QBZappy

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.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

Robert.Thompson

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.
Rob. (Obi newbie.)

OBi 110 using Anveo - but presently testing AcroVoice
My blog: www.googlevoiceforcanadians.com

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
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

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.