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
