based on the VIA branch param, TM identifies if the upstream UA uses pre-RFC3261 or RFC3261 matching (if RFC3261 is supported, the branch via param will start with "z9hG4bK")
regards, bogdan
Papadopoulos Georgios wrote:
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@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@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