Re: How to handle connectivity when the other side is misconfigured?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Robert,

in the openLogicalChannelAck they are telling your GnuGk the RTP
destination port and a private IP doesn't work for that.

There isn't really much you can do about misconfigured endpoints other
than configuring it correctly. What you can do is provide a
H.460.18 enabled gatekeeper on a public IP and ask these folks to
register with it for the duration of the call.

Regards,
Jan

Robert Kulagowski wrote:
> NAT / PAT is evil.
> 
> I have some remote sites outside of my control that don't know how to
> configure their video equipment, and won't put their video systems
> outside of their firewall.
> 
> So, they can connect to me, but then complain that they can't see/hear us.
> 
> I'm assuming that the following snippet is why it's not working.
> 
> 2012/02/28 13:31:21.079 4       ProxyChannel.cxx(7784)  H245
> Response: openLogicalChannelAck
> 2012/02/28 13:31:21.080 5       ProxyChannel.cxx(6742)  RTCP
> Reverse 10.202.19.99:3236 to 10.244.1.15:50549
> 2012/02/28 13:31:21.080 5       ProxyChannel.cxx(6742)  RTP
> Reverse 10.202.19.99:3235 to 10.244.1.15:50548
> 2012/02/28 13:31:21.080 5       ProxyChannel.cxx(9009)  ProxyRTP(0)
> total sockets 34
> 2012/02/28 13:31:21.080 5       ProxyChannel.cxx(1663)  H245    To
> send: response openLogicalChannelAck {
>     forwardLogicalChannelNumber = 2
>     forwardMultiplexAckParameters = h2250LogicalChannelAckParameters {
>       sessionID = 1
>       mediaChannel = unicastAddress iPAddress {
>         network =  4 octets {
>           26 7c 27 fe                                        &|'.
>         }
>         tsapIdentifier = 56906
>       }
>       mediaControlChannel = unicastAddress iPAddress {
>         network =  4 octets {
>           26 7c 27 fe                                        &|'.
>         }
>         tsapIdentifier = 56907
>       }
>     }
>   }
> 2012/02/28 13:31:21.111 5       ProxyChannel.cxx(803)   H245s
> Reading from 204.101.117.205:24144
> 2012/02/28 13:31:21.111 4       ProxyChannel.cxx(1426)  H245
> Received from 204.101.117.205:24131: request openLogicalChannel {
> 
> The remote system connection is coming from 204.101.117.205, but the
> embedded IP address that's coming through is 10.202.19.99. Am I
> correct in thinking that GnuGK is then trying to open a session with
> the 10.202.19.99 address and failing, which is why they can't see us?



-- 
Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________________

Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/


[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux