On Tue, Feb 8, 2011 at 8:41 AM, <[email protected]> wrote: > Not really a solution to the problem IMHO. TCP should work as well. > (.............and as old SNA and ATM guy I like connections.......) > > Anyhow, I wanted to get to the bottom of this and found the following: > (this is all on SipX 4.2.1 and Bria 3.1.2.1) > > 1) Use of rport is not a problem if the firewall traversal method of Bria > is configured as "None" > In this case a registration looks like Case1.cap > The standard 2 REGISTER requests are send. > 2) Use of rport is a problem if firewall traversal method is set to > "Automatic" > In this case a registration looks like Case2.cap > The big difference is that Bria sends 2 additional REGISTER messages, > this somehow makes SipX think it has to use the other port > 3) Not using rport works OK as well with "Automatic" > Just 2 REGISTERS again, no rinstance is used, Case3.cap > 4) Not using rport and "None" works as well. > Just 2 REGISTERS again, no rinstance is used, Case4.cap > > I added a readable file of the Registration process as well for ease of > reading. > > As said, in case 2 two additional REGISTER's are send by Bria. > I'm no sure the register expires=0 is an issue... read on
> The 3th, (so first additional) REGISTER has expires=0, but in the wrong > place, behind the Contact field > The 4th REGISTER seems OK to me. > > Now the question: is this a Bria problem because the 3th REGISTER is > malformed > or is this a SipX problem because it should be able to handle this ..or > ..... > > It should not b set to automatic anyway. That was in a patch on the wiki, and should be addressed in 4.4 (setting firewall=none for the traversal method). If none of these issues occur with it as NONe, is it really a problem, since it should be the default? > Regards, Paul > > > > > From: > Tony Graziano <[email protected]> > To: > [email protected] > Date: 07-02-2011 18:41 Subject: Re: [sipx-users] Problems with HA-setup, > UDP and TCP ports mixed up, only 50% of calls come through Sent by: > [email protected] > ------------------------------ > > > > If it matters (or not) but I thought I saw in the 3.2 beta that you could > "force" bria to use udp? Or was that my imagination? > ============================ > Tony Graziano, Manager > Telephone: 434.984.8430 > Fax: 434.984.8431 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > ----- Original Message ----- > From: [email protected] > <[email protected]> > To: Discussion list for users of sipXecs software > <[email protected]> > Sent: Mon Feb 07 11:43:56 2011 > Subject: Re: [sipx-users] Problems with HA-setup, UDP and TCP ports mixed > up, only 50% of calls come through > > Made myself floating again..... > > rport was enabled on Bria by accident. > Disabled it and now it seems to be OK again.............. > > Still weird that this happened. > rport was invented for UDP, not for TCP, and I cant really find in the RFC > http://www.faqs.org/rfcs/rfc3581.html what the behaviour should be when > using TCP. > > If someone wants to shine a light on this, much appreciated. > > Paul > > > > From: > [email protected] > To: > Discussion list for users of sipXecs software > <[email protected]> > Date: > 07-02-2011 17:34 > Subject: > Re: [sipx-users] Problems with HA-setup, UDP and TCP ports mixed up, only > 50% of calls come through > Sent by: > [email protected] > > > > Blub Blub > > Below the trace of my Bria provisioning itself from server A, and then > telling server A it wants to use port 30980 (see packet 23). > In packet 32 we see server A contacting Bria on port 30980, that's OK. > In packet 40 we see server B's attempt to connect to Bria on port 10198, > wrong port, no connection, call fails, bad luck, need help. > > Paul > > > > > From: > [email protected] > To: > Discussion list for users of sipXecs software > <[email protected]> > Date: > 07-02-2011 14:00 > Subject: > Re: [sipx-users] Problems with HA-setup, UDP and TCP ports mixed up, only > 50% of calls come through > Sent by: > [email protected] > > > > > And for comparison a trace of a Bria that has no problems, look at the > ports being used. > > Working Case: > Proto Client Server A Server B > 10.22.3.34 10.31.48.25 10.32.48.25 > UDP 30004 5060 > TCP 1232 5060 > TCP 30004 5060 > > 50% Case: > Proto Client Server A Server B > 10.3.203.150 10.31.48.25 10.32.48.25 > UDP 30300 5060 > TCP 1312 5060 > TCP 1312 60618 (Syn from Server B to A, > RST-ed by A) > > > The UDP port was missing from the first trace, so I made a separate trace > to show the UDP port. > > > Paul > > > From: > [email protected] > To: > Discussion list for users of sipXecs software > <[email protected]> > Date: > 07-02-2011 12:35 > Subject: > Re: [sipx-users] Problems with HA-setup, UDP and TCP ports mixed up, only > 50% of calls come through > Sent by: > [email protected] > > > > > > Sorry, some extra info: > 10.1.248.31 is the GW (patton). > The Patton doesn't like to use the same port (5060) to 2 different SipX > clusters. > So I configured it to use port 5061 as source port for my second SipX > HA-pair. > See part of the Patton config below: > context sip-gateway gssipx02 > > interface TH-sip > bind interface LAN context router port 5060 > > context sip-gateway gssipx02 > no shutdown > > context sip-gateway mssipx02 > > interface MN-sip > bind interface LAN context router port 5061 > > 10.31.48.25 is server A and 10.32.48.25 is server B > 10.3.203.150 is the PC with Bria. > > I think things start to go wrong in packet 23, that Syn should have gone > to port 30300 (the UDP port used by Bria to server A, port 5060, see > capture A) > and not to 1312 (the TCP port used by Bria towards server A, port 5060, > again, see capture A). > > Paul > From: > Tony Graziano <[email protected]> > To: > Discussion list for users of sipXecs software > <[email protected]> > Date: > 07-02-2011 11:59 > Subject: > Re: [sipx-users] Problems with HA-setup, UDP and TCP ports mixed up, only > 50% of calls come through > Sent by: > [email protected] > > > > > > > its opening a tls connection (port 5061)? > > frame 21 (capture b) shows the source port for the invite to come from > sipx on port 5061, and i (also) don't understand why it would do that. > > On Mon, Feb 7, 2011 at 5:34 AM, <[email protected]> wrote: > Maybe someone can look at the traces attached. > The trace ServerA.pcap is taken on the sipserver that holds the > registration. This server is sending the invite over the existing session > and all works. > The trace ServerB.pcap is taken on the other server and this one tries to > open a session to the phone on the wrong port (if I am not mistaken). > This is RST-ed in packet 24 and then S-B sends an invite to the IVR. > > If wanted I can send a snapshot from S-B or both servers. > > Please advise what to do. > > Paul > From: > [email protected] > To: > [email protected] > Date: > 04-02-2011 16:07 > Subject: > [sipx-users] Problems with HA-setup, UDP and TCP ports mixed up, only 50% > of calls come through > Sent by: > [email protected] > > > > > > > > > For the second time in a looong time I have the problem that only 50% of > the calls from a GW to a SIP-phone come through, the other 50% go to > voicemail directly. > I have an HA setup and the GW is distributing the calls round-robin to the > 2 SipX servers that form an HA-cluster. > Also calls from phones registered on one server (S-A) of the HA cluster to > a phone with the problem on the other server (S-B) will go to voice mail > directly. > I am using 4.2.1-018971 and Bria 3.1.2.1 > > Most phones (Bria's) work OK, but some show the following behaviour: > When the call flows to the SipX server (S-A) that holds the registration > for that phone then the phone starts ringing. > When the call flows to the other SipX server (S-B) then you go to > voicemail directly. > > I have traced a working Bria and one with the problem. The difference lies > in the port that is being used to send the invite on. > BTW: my phones are configured to use TCP. > > In the normal case the phone registers from port A to 5060 (syn, syn ack > etc) on S-A. > The phone then sends some Notify requests over UDP from port B to 5060 on > S-A. > If the call flows through S-A (the server that holds the registration) > then the existing session (5060 to port A) is used. > If the call flows through S-B then the server sends a SYN from a random > port to the phone to port B (so the same port that the phone used to > communicate with S-A for UDP communication) > This is SYN-acked and all goes well. > > In the case of the problem all is the same for S-A and these 50% of the > calls work. > If the call flows through S-B however then the SYN is not send to port B > (the UDP port used by the phone between phone and S-A), but to port A (the > TCP port of S-A). > This SYN is generously RST-ed and you end up in voicemail. > > I found a really old issue, http://track.sipfoundry.org/browse/XCL-89 > maybe something like this can happen very rarely as well. > > If needed I can send wiresharks, snapshots or anything else, please let me > know. > > Restarting services does not help. > Resetting the servers one at a time does not solve the problem as well. > The only remedy so far that sort of works is resetting both servers at the > same time. > > > Paul_______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > Fax: 434.326.5325 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected] > > Helpdesk Contract Customers: > http://support.myitdepartment.net > > Blog: > http://blog.myitdepartment.net > > Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ [attachment > "OK-ServerB.cap" deleted by Paul Scheepens/EPO] [attachment > "OK-ServerA.cap" deleted by Paul Scheepens/EPO] [attachment > "OK-ServerA-udp.pcap" deleted by Paul Scheepens/EPO] > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ [attachment > "Register-BNOK.pcap" deleted by Paul Scheepens/EPO] > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
