Re: [Users] Receiving different VIA in INVITE and CANCEL

Aaah, I see... So how does TM work? Does it try first the pre-RFC3261 and then the RFC3261? Thank you George >-----Original Message----- >From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] >Sent: Wednesday, February 08, 2006 4:05 PM >To: Papadopoulos Georgios >Cc: users(a)openser.org >Subject: Re: [Users] Receiving different VIA in INVITE and CANCEL > >George, > >there are two algs for transaction matching: > - the pre-RFC3261 one - a set of hdrs and RURI are used >to match the CANCEL to the original INVITE > - the RFC3261 alg - the cookies and ID from the branch >VIA param is used. > >via1_matching and ruri_matching are options only for the >pre-RFC3261 alg. > >regards, >bogdan > >Papadopoulos Georgios wrote: > > > >>Hi Bogdan, >> >>I will try the force_rport(). >> >>Meanwhile I am confused by what you wrote. Can you please clarify? >> >> >> >> >>>The problem is the different port in via. The "via1_matching" >>>param has no effect on RFC3261 transaction matching algorithm since >>>this is entirely based on via :). >>> >>> >>> >>> >>thanks a lot >> >>George >> >> >> >> >> >>>-----Original Message----- >>>From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] >>>Sent: Wednesday, February 08, 2006 11:43 AM >>>To: Papadopoulos Georgios >>>Cc: users(a)openser.org >>>Subject: Re: [Users] Receiving different VIA in INVITE and CANCEL >>> >>>Hi Geroge, >>> >>>it looks like your device uses STUN to perform nat traversal (the >>>callid has a private IP). The improper nat traversal via >>> >>> >STUN is the > > >>>reason for the different port in VIA; to fix this, call >>>"force_rport()" >>>in the beginning of your script for all requests. >>> >>>now, going back to the CANCEL matching....SIPURA uses the >>>RFC3261 transaction matching algorithm (based on some >>> >>> >cookie and ids > > >>>stored in branch VIA param. These are matching in your case, but >>>openser uses as additional checkings the via host, port and proto >>>(just to be sure that the originator matches too to avoid confusion >>>with different senders generating the same cookie/id). >>>The problem is the different port in via. The "via1_matching" >>>param has no effect on RFC3261 transaction matching algorithm since >>>this is entirely based on via :). >>> >>>my suggestion is to fix the nat traversal part. >>> >>>regards, >>>bogdan >>> >>>