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
_______________________________________________
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
