[VoiceOps] Bad/not unique SIP Call-ID GUIDs

[Alex Balashov]

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/