On 08/02/2010 12:56 PM, Scott Berkman wrote:
Not something I'd ever come across, but the best solution I would think would be to create an auto-increment key that is unique (based on incrementing vales) within the database.
Well, yes, unique primary keys are great. :-) That's what I'd ordinarily do with a Call-ID in many situations, and that's what's causing the problem; when there is a primary key collision, the entire transaction is rolled back. The problem, which I mentioned but perhaps underemphasised, is that I need a value that is not only unique but occurs straightforwardly within the SIP message body itself, so that it is possible to easily associate messages at a higher level of abstraction. That's the purpose that a Call-ID is intended to serve.
You can also look into what system it is that is producing the non-unique call IDs and try to work with that Vendor. In theory, non-unique call ID's could really mess up the state of a UA. Tags are normally meant to help combat that, but this kind of thing is where SIP implementations (and the underlying interpretations of the RFC's) really vary.
Tags are dialog-bound identifiers. The beauty of the Call-ID is that it unites a superset of messages, including many sequential interactions which do not form a dialog. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/