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. Both the UAs are registered (I confirmed from the web interface registration screen). It does not look like the via from proxy is fragmented. Each via has a different branch parameter though emerging from the same endpoint (Can someone tell me in what cases the via header will get fragmented and how the fragmented vias looks like?)
****************Invite from sipxproxy (192.168.50.52) to dest-UA ( 192.168.50.204), the lowest Via header corresponds to the source UA (IP-192.168.50.205) ***************** INVITE sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]> SIP/2.0 Record-Route: <sip:192.168.50.52:5060 ;lr;sipXecs-rs=%2Afrom%7EYzBhODMyY2QtMTc%60.400_authrules%2Aauth%7E%211590e935cd4ae900a36d10202f501d7c> Call-Id: [EMAIL PROTECTED] Contact: <sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]>> Content-Length: 249 Content-Type: application/sdp Cseq: 1 INVITE From: <sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]>>;tag=c0a832cd-17 Max-Forwards: 16 Min-Se: 600 Session-Expires: 3600 Session-Guid: 859321956-1634023014-905969664-2513471912 Supported: 100rel,timer To: <sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]>> User-Agent: Quintum/1.0.0 SN/0030E12004B0 SW/P106-11-00 Via: SIP/2.0/UDP 192.168.50.52 ;branch=z9hG4bK-sipXecs-0137aac61e5301ead76e6566cdb0f2d3be5e Via: SIP/2.0/UDP 192.168.50.52 ;branch=z9hG4bK-sipXecs-0134499c81a909946eaed847046c2535f409%e8c783cad7ee777c922618d09949ebd4 Via: SIP/2.0/UDP 192.168.50.52 ;branch=z9hG4bK-sipXecs-012ea2e73188173f014705446d987568ab32%dbb67e4f9a5bca399689a4d127429e37 Via: SIP/2.0/UDP 192.168.50.205;branch=z9hG4bK-tenor-c0a8-32cd-0033 ******************************************************************************************************** #######################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 ###########################################################################3 Does the sipx proxy behave the same for all of you? Do you receive 3 via headers from the proxy and then your UAs consider them as fragmented via header and still work alright? Please let me know. Thanks, Padmaja On Thu, Jun 12, 2008 at 9:06 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > On Thu, 2008-06-12 at 10:46 -0400, Hegner, Travis wrote: > > >If the UA ignores INVITEs that have four Via headers, it is *severely* > broken. > > > > Not necessarily... > > > > I have a similar problem where my provider won't accept fragmented UDP > > packets, nor will they accept SIP over TCP. IMO this is a shortcoming > > of sipx that should be addressed. A single SIP Proxy should only > > require a single via header. Sipx is very liberal with the packet size > > consider there isn't much room to work with before the packet becomes > > fragmented. > > > > My temporary work around for this is to use a stripped down asterisk > > box for forwarding calls only. It re-originates the call and therefore > > eliminates all previous via headers from it's point out. I recommend > > using the "canreinvite" features of the SIP trunks in asterisk to > > allow direct media. > > The sipXbridge that is in the 3.11 development builds also reoriginates > calls, partly for this reason. > > That doesn't change the fact that a SIP implementation that can't > reassemble fragmented UDP and can't use TCP is badly broken. > > -- > Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]<[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
