Now to provide a complete answer to the question: the values are supposed to be unique according to RFC3261 but there is nothing in the world that prevents broken implementations to generate invalid non-unique values. There are indeed implementations that are broken. To make CDRs as much unique as you can, compose the identifier as a triple callid-fromtag- totag. Composition of values generated by UACs and UASs significantly reduces the chance of not being unique.
-jiri
At 06:23 PM 8/12/2004, Michael Shuler wrote:
The call-id is supposed to be unique across a complete session i.e. INVITE/RINGING/OK/ACK/BYE. If it wasn't then there would be no way to relate the messages as part of the same sequence/call.
Michael Shuler, C.E.O. BitWise Systems, Inc. 682 High Point Lane East Peoria, IL 61611 Office: (217) 585-0357 Cell: (309) 657-6365 Fax: (309) 213-3500 E-Mail: mike@bwsys.net Customer Service: (877) 976-0711
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Arnd Vehling Sent: Thursday, August 12, 2004 10:47 AM To: serusers@lists.iptel.org Subject: [Serusers] From-Tag/Call-id not uniq?
Hi,
according to the RFC:
"When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness."
But when looking at a sip logfile:
egrep "^From:.*;tag=9d49295bb825210f" /var/log/term.log | wc -l 503
Question: Did i understood something wrong or is the recoccurance of the same tag-id and callid in different sessions voilating the rfc?
Ive found loads of non-uniq call-ids as well as non uniq tags. How is a man supposed to make accounting (besides accounting on the PSTN GW/Voice Switch) when those to identifiers are not globally uniq?
So far ive seen non uniq callids from Grandstream Products and non uniq tags from sipura adapters.
:: arnd ::
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Jiri Kuthan wrote:
Now to provide a complete answer to the question: the values are supposed to be unique according to RFC3261 but there is nothing in the world that prevents broken implementations to generate invalid non-unique values. There are indeed implementations that are broken. To make CDRs as much unique as you can, compose the identifier as a triple callid-fromtag- totag. Composition of values generated by UACs and UASs significantly reduces the chance of not being unique.
Why does the formulation "significantly reduces the chance of not being unique" make me nervous? :)
May it be that the "SIP RFC Fathers" neglected the real-word issue of actually accounting sip-calls a bit? Making accounting dependant on client side software implementations doesnt seem a basicly good idea to me.
:: arnd ::
At 12:06 PM 8/16/2004, Arnd Vehling wrote:
Jiri Kuthan wrote:
Now to provide a complete answer to the question: the values are supposed to be unique according to RFC3261 but there is nothing in the world that prevents broken implementations to generate invalid non-unique values. There are indeed implementations that are broken. To make CDRs as much unique as you can, compose the identifier as a triple callid-fromtag- totag. Composition of values generated by UACs and UASs significantly reduces the chance of not being unique.
Why does the formulation "significantly reduces the chance of not being unique" make me nervous? :)
I don't know, I am not a psychologist ;)
May it be that the "SIP RFC Fathers" neglected the real-word issue of actually accounting sip-calls a bit? Making accounting dependant on client side software implementations doesnt seem a basicly good idea to me.
That's why RFC3261 identifies dialog by the triple, which includes server-generated to-tag. Obviously if clients and servers agree to generate stupid triple {from-tag, callid, to-tag}, accounting can still mess, but I don't see this case as a huge issue.
-jiri
-
Arnd Vehling -
Jiri Kuthan