« Back to Call Detail Records Questions

cause codes as integer or long

Combination View Flat View Tree View
Threads [ Previous | Next ]
cause codes as integer or long
Answer
2/12/10 10:36 PM
In reading the CDR spec, it doesn't specifically call out the type for cause codes definitions.  It seemed for a long time to be just an integer but with the addition of recent CCM SIP codes, that assumption was wrong.  for example, these code values fall outside the size of an int
 

2701131793 CCM_SIP_600_BUSY_EVERYWHERE
2717909013 CCM_SIP_603_DECLINE
2734686209 CCM_SIP_604_DOES_NOT_EXIST_ANYWHERE
2751463455 CCM_SIP_606_NOT_ACCEPTABLE
 
My question is was this a conscious decision or by accident and should be corrected?  It seems strange to have just a few codes be so large requiring the extra allocation for a long value.
Flag

RE: cause codes as integer or long
Answer
2/12/10 10:36 PM as a reply to David Roberts.
I'm not sure what the reasoning is behind the large values, but they do fit within (unsigned) integer range.
 
Decimal value: 2701131793
Token: CCM_SIP_600_BUSY_EVERYWHERE
Hex value: 0xA1000011
 
As you can see with the hex value, it still fits within 32 bits.  If you have a large installed base of code/data that uses signed ints, perhaps you can 'stuff' the value in by converting to a modulo-two/negative value.
Flag

RE: cause codes as integer or long
Answer
2/12/10 10:36 PM as a reply to David Staudt.
Ugh, I think it is a signed issue.  We collect the CDRs and store into Postgres which has type 'int' which is a signed 4 bit integer.  In order to store these few SIP codes, we have to increase it to bigint which is a waste or space and means quite a few other changes in our code. 
 
In looking at the other CDR columns, I see a similar issue and the headings just say INTEGER without specifying the max size or whether they should include sign.  For example, in CMR, there are numberOfPacketsSent (INTEGER).  Clearly for a long enough phone call this number will outgrow any Integer, signed or not. 
 
 
Flag

RE: cause codes as integer or long
Answer
2/12/10 10:36 PM as a reply to David Roberts.
I guess minimum storage size will need to be 32 bits per value, which appears to be the default storage size for Postgres 'integer' type: http://www.postgresql.org/docs/8.1/static/datatype.html#DATATYPE-INT, though Postgres appears to expect the high order bit to be the sign.
 
Check my math, but I think for numberOfPacketsSent:
 
At 20ms packets, 50 packets = 1 second
 
4294967295 packets (32 bit field max) = 85899345.9 seconds = 23860.93 hours
 
Never say never, but that would be a pretty long call
 
Flag

RE: cause codes as integer or long
Answer
2/12/10 10:36 PM as a reply to David Staudt.
Yes, Postgres integer is 32 bit but is signed so can't seem to handle the larger number right?
 
For numberOfPacketsSent, your math seems right so maybe these are unrelated (the negative sign is how postgres seems to be interpreting large cause codes values).  I guess this leads me to another question is why would we get a negative number as numberOfPacketsSent.  I'm seeing
-2121571050 when I open the raw CMR file in notepad or Excel.
 
 
Flag