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