> > Woof! > > > > On Thu, 13 Nov 2008 16:33:01 -0500, Joly, Robert (CAR:9D30) > > <[EMAIL PROTECTED]> wrote: > > > > > Interesting observation. Is there any way for you to point > > your phone > > > to an older system to compare the traces? > > > > Here is the same call flow, on the same phones, running against 3.10 > > > > The biggest difference between the two call flows is that the > 3.10 trace uses UDP whereas the 3.11.8 trace uses TCP. The > NAT traversal feature introduces new headers and URL > parameters which increases the size of the message. One > possibility is that the recent merge of the NAT traversal > code pushed the size of the message beyond 1300 which caused > TCP to get used and perhaps there is a TCP incompatibility > between Snom and sipXecs. The other possibility is that the > new headers and URL params confuse the Snom phone. > > I may have a Snom phone here. I'll try to configure it for > TCP only and point it at a 3.10 system to see what happens. > I'll post back to let you know the results.
I finally managed to assemble all the pieces I needed to conduct my test. I registered the phone against a sipXecs 3.10.3. I used that version because it has Kathy's code that switches to TCP on messages larger than 1300 bytes but none of the more recent features like NAT traversal, PAI and sipXbridge. I first made a basic call to it and things worked - that call used UDP because of the modest size of the INVITE. I then created a set of dialplans to cause some spiraling and bump up the INVITE message size - I then called the Snom again. Given the size of the INVITE, the message was sent via TCP and a failure identical to yours was observed. The cause of the problem is what Arjun highlighted earlier: Snom sends a response to the INVITE with a Contact that is different from the contact it registered against. When we send the BYE to the Contact we got from the response, we get a TCP reset indicating that Snom is not listening on that port. I think that this is a pretty fundamental issue with the Snom phones and one that should be raised. Recent features such as PAI and NAT Traversal have increased the message size causing more traffic to go over TCP. That likely explains why we are starting to see this failure. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
