Padmaja, When I referenced fragmentation, it is not the actual via header that gets fragmented, but the entire UDP packet. If a data packet gets too large, the network equipment will split it up into two packets. The extra via headers that sipx puts in, could very easily be putting your sip packet above the recommended 1300 byte threshold, and if your phone does not re-assemble the packet properly it may not function correctly.
I ran into the same problem with my provider because they don't properly re-assemble the packets, thereby causing the call to fail. My provider is still testing its TCP implementation, so it's for production use yet. TCP has much better control over fragmentation because it is not a stateless protocol. The only really good way to see this is with a packet capture program like wireshark. While UDP fragmentation works with most SIP implementations, there are a few where it can cause some grief. If you research UDP fragmentation, you will see that it is very highly recommended to avoid it. Not just for SIP, but for any application that runs on UDP, since UDP is stateless and does not have any traffic flow control mechanisms. Travis -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Graziano Sent: Friday, June 13, 2008 8:54 AM To: [EMAIL PROTECTED]; [email protected]; [EMAIL PROTECTED] Subject: Re: [sipx-users] sipxproxy failed at startup No. First setup named and add the records for the DNS SRV and let sipx look at its own DNS for SRV lookups. You might also have the tenor gateway use the DNS on sipx too. Is this an FXS gateway? If so, this should take care of it. >>> "Padmaja R" <[EMAIL PROTECTED]> 6/13/2008 8:33:05 AM >>> Hi, Thanks for the reply, I however do not have Cisco phone, it is a Quintum product called Tenor. I will find out if it is failing at the % character. So, in SIPXecs, does the proxy fragment the Via header and put it in two separate vias or it does some kind of spiral and loop testing? (Again thanks for your reply on the SIP implementor's forum on 2 different Vias). On a different note, you mentioned above that out of the 3 via headers one can be eliminated by having DNS SRV records. I am currently using IP addresses to register and make calls. I have nt configured the DNS on the SIPX PC. Does this mean I have to undo everything and install from scratch? Thanks, Padmaja On Fri, Jun 13, 2008 at 5:37 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > On Fri, 2008-06-13 at 11:27 +0530, Padmaja R wrote: > > Hi all, > > > > My UAs can handle both TCP and UDP. The Invite received via both the > transports has the same number (3) via headers from the same IP (the SIPX > proxy) and that is where my UA stops processing the Invite. I should have > attached the logs from my UA for better understanding of everyone. Please > find below the Invite sent from SIPXproxy to UA and where the decoding of > headers is failing. > > > #######################Failing to decode Invite with 4 via headers at the > dest-UA-192.168.50.204############### > > [syn]:decoded token Record-Route > [syn]:MessageHeader_t:: decoded token Call-Id > [syn]:MessageHeader_t:: decoded token Contact > [syn]:MessageHeader_t:: decoded token Content-Length > [syn]:MessageHeader_t:: decoded token Content-Type > [syn]:MessageHeader_t:: decoded token Cseq > [syn]:MessageHeader_t:: decoded token From > [syn]:MessageHeader_t:: decoded token Max-Forwards > [syn]:MessageHeader_t:: decoded token Min-Se > [syn]:MessageHeader_t:: decoded token Session-Expires > [sess]:MessageHeader_t:: decoding SessionExpiresHeader_t > [syn]:MessageHeader_t:: decoded token Session-Guid > [sess]:MessageHeader_t:: decoding SessionGUIDHeader_t > [syn]:Session GUID 859321956, 1634023014, 905969664, -1781495384 > [syn]:MessageHeader_t:: decoded token Supported > [sess]:SupportedHeader:: decoding 100rel > [sess]:SupportedHeader:: decoding timer > [syn]:MessageHeader_t:: decoded token To > [syn]:MessageHeader_t:: decoded token User-Agent > [syn]:MessageHeader_t:: decoded token Via > [syn]:MessageHeader_t:: decoded token Via > [syn]:RequestMessage:: decoding headers failed > [syn]:SipMessage FAILED decode > > > I suspect that you've run into XECS-1382<http://track.sipfoundry.org/browse/XECS-1382>- the UA is decoding the Vias and misinterpreting the % character in one of > the values. We've changed that to a '~' in 3.10.2, the final release of > which should be very soon. Are these Cisco phones (that's where we've seen > this before)? > > -- > Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED] > sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs > CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/ > http://www.pingtel.com/ > > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
