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:[EMAIL PROTECTED]
Sent: Wednesday, February 08, 2006 4:05 PM
To: Papadopoulos Georgios
Cc: [email protected]
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:[EMAIL PROTECTED]
Sent: Wednesday, February 08, 2006 11:43 AM
To: Papadopoulos Georgios
Cc: [email protected]
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
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
