[Users] Receiving different VIA in INVITE and CANCEL

[Bogdan-Andrei Iancu]

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 at voice-system.ro] 
>>Sent: Wednesday, February 08, 2006 4:05 PM
>>To: Papadopoulos Georgios
>>Cc: users at 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 at voice-system.ro]
>>>>Sent: Wednesday, February 08, 2006 11:43 AM
>>>>To: Papadopoulos Georgios
>>>>Cc: users at 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
>>>>        
>>>>