Hello,

have you created the transaction before calling registrar/usrloc functions (e.g., using t_newtran())? You seem to want to match from transaction point of view.

Registrar is matching based on contact, that being the key for the registrations -- there are some module parameters that allow different matching options.

Cheers,
Daniel

On 7/25/13 11:46 AM, Shankar wrote:

Hi,

 

We are testing the REGISTRAR with kamailio.

 

We tested the following scenario ,

 

è Register Request with contact ‘A’.

è 200 OK received for the request

è Second Register request with contact ‘B’. (Requet-URI, To Tag, From tag, call-id, and Cseq -> all same as the first register request)

è 200 OK received for the request.

 

When we checked the ‘location’ table entry, two records were found for the same user with different contact addresses.  

 

Please find below the RFC extract below,

 

Section 17.2.3

   For all other request methods, a request is matched to a transaction

   if the Request-URI, To tag, From tag, Call-ID, CSeq (including the

   method), and top Via header field match those of the request that

   created the transaction.  Matching is done based on the matching

   rules defined for each of those header fields.  When a non-INVITE

   request matches an existing transaction, it is a retransmission of

   the request that created that transaction.

 

My understanding is that the second register request should be considered as duplicate and rejected.

 

Please share your feedback on the same.

 

Regards,

Shankar



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda