On Tue, 2009-05-12 at 12:59 -0400, Joly, Robert (CAR:9D30) wrote: > > > -----Original Message----- > > From: Tony Graziano [mailto:[email protected]] > > Sent: Tuesday, May 12, 2009 12:58 PM > > To: Joly, Robert (CAR:9D30) > > Subject: RE: [sipx-users] Remote Worker Questions > > > > >>> "Robert Joly" <[email protected]> 05/11/09 8:22 PM >>> > > > In testing, I am having a hard time getting NAT Traversal > > to function > > > the way I assumed it would for remote workers. > > > > > > I assumed if the remote worker had a personal > > firewall/router it would > > > traverse and work, but so far have not found this to be the case. > > > > This is the intent and I'm still trying to figure out why the > > proxy immediately times out on your request. If you could > > send me a snapshot with sipXproxy debug turned on, that would > > be very helpful at this point. > > > > > > > > > > In every case I can register the user and call sipx (AA, VM, other > > > users). I can even dial out via the sip trunk. In every > > case dialling > > > out via the sip trunk has broken audio (non-existent). Local users > > > cannot call the remote worker. > > > DID calls get sent directly to voicemail instead of ringing. > > > > > > The only way I have seen it work is if the remote worker > > phone/PC has > > > a PUBLIC IP address and no NAT at the other end. > > > > From the POV of the far-end NAT traversal feature, this is > > not considered a remote worker. > > > > > > > > Example: Registrations like this do not work: > > > > > > <sip:2...@public_ip_address_from_isp;rinstance=5734ce2f7e265247 > > ;transport=TCP;x-sipX-privcontact=PRIVATE_IP_ADDRESS_ON_LAN%> > > 3A10892%3Btransport%3DTCP> > > > > > > Whereas registrations like this do: > > > > > > <sip:2...@public_ip_address_from_isp:3062;rinstance=5fda7fd7c30 > > a4dab;transport=TCP;x-sipX-nonat> > > > > > > I have an instance to want to set up two remote workers on a single > > > Internet connection. > > > > > > Is this possible? > > > > It is possible but there's no point in trying that just yet > > given we cannpt get the iimple case to work. > > > >
Looking more closely, the 408 response is caused by changes to tighten the TCP timeout, it was 500ms, it is now 100ms. Change was in r14599 due to XX-4699 (nee XECS-1589) "SipXecs does not gracefully handle broken TCP streams" Dale has seen problems with this with various phones and brought it to the dev-list http://list.sipfoundry.org/archive/sipx-dev/msg17812.html I think the 408 is a red-herring in this case anyway. I haven't figured out why proxy doesn't roll to udp after tcp time-out... in sipXproxy.log we get tcp and udp from dns lookup "2009-05-12T16:54:41.371373Z":8623:SIP:DEBUG:pbx.myitdepartment.net:SipClientTcp-39:B639BB90:SipXProxy:"SipSrvLookup::servers domain = '10.255.252.98', service = 'sip', socketType = UNKNOWN, port = 5060" "2009-05-12T16:54:41.371475Z":8624:SIP:DEBUG:pbx.myitdepartment.net:SipClientTcp-39:B639BB90:SipXProxy:"SipSrvLookup::servers host = '10.255.252.98', IP addr = '10.255.252.98', port = 5060, weight = 0, score = 1000.000000, priority = 0, proto = TCP" "2009-05-12T16:54:41.371492Z":8625:SIP:DEBUG:pbx.myitdepartment.net:SipClientTcp-39:B639BB90:SipXProxy:"SipSrvLookup::servers host = '10.255.252.98', IP addr = '10.255.252.98', port = 5060, weight = 0, score = 1000.000000, priority = 0, proto = UDP" but instead of trying udp, the 408 is sent upstream internally, causing the upstream transaction tree to roll to voicemail. The vm request is sent via udp, which is also currently puzzling. still looking, -Kathy _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
