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> 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>wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSHcgfAAoJEKRZG9Ehk6ybKZQH/3MvKC1QBmgX+6mH3fwnZWcI ezJ2XxL6EX+09uqBTbXnk2i8AJHMhZbMAokKJuMcyZHfJvOcQiBnj66fK7njPSBX A5/6ieXEzsxI+QHSu26t1pnhFLltgvkOGD2wVVf0e+bQhu027zDM6WW46IJtx3oa NBK3gC/oFOw/by0ejeEHsWOwpUvtimEdFRgSJFOYA03L+SEQWQn34uoiCC0fMHmS yKt1axCU04GDeN9nIEhrJTC+n/B5BiK4FcwbeMeUvj/VrK/+i57XCF+Wnr2qWJjy kBo4Rg1nDURw3nfQiBOhJ27ja5G4kUFAfiJzHs0/yjEsl233Ovakl6GIiwvlkpk= =+QMf -----END PGP SIGNATURE-----

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900

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