Thank you for your answers. I'll try to see whether it is worth to maintain a transition table for traceability instead of using the option then. Best Kim On 2013-08-28 21:50, Steven Ayre wrote:
Another thing is storage... if your DB structure is assuming UUIDs are of the normal length, then longer Call-IDs are going to cause you truncation problems.
On 28 August 2013 20:14, Anthony Minessale <anthony.minessale@gmail.com <mailto:anthony.minessale@gmail.com>> wrote:
Correct, you are at the mercy of the call-id being unique and uniqueness cannot be guaranteed. Many sip endpoints at least try pretty hard to make sure they are unique but there is really nothing to enforce it.
Alternatively, you do have the sip_call_id variable present so its not that hard to correlate them.
On Wed, Aug 28, 2013 at 1:40 PM, Ben Langfeld <ben@langfeld.co.uk <mailto:ben@langfeld.co.uk>> wrote:
I would imagine the issue is that an incoming INVITE CallID might not strictly be unique. I'm not sure if "use-callid-as-uuid" deals with this at all...
On 28 August 2013 06:51, Kim Rostgaard Christensen <krc@retrospekt.dk <mailto:krc@retrospekt.dk>> wrote:
Hi list
First post, so I would just like to give a big hat tip to the people involved - extremely nice project. Well documented, nice community We recently moved from Asterisk to FreeSWITCH, and have not looked back since. Asterisk is a very nice project, but AMI is less suited our needs than ESL.
Today, while mucking about with PJSUA, I discovered the call_id to be (entirely) different from the uuid assigned to the channel in FS. While this appears to remedied by the *-use-callid-as-uuid options in sofia.xml I still wonder if there are any potential complications/slowdown associated with using the option?
Best
-- Kim Rostgaard Christensen | krc@retrospekt.dk | http://retrospekt.dk