Created by: David Roberts on 12-02-2010 04:36:43 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.
Subject: RE: cause codes as integer or long Replied by: David Staudt on 12-02-2010 04:36:43 PM 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.
Subject: RE: cause codes as integer or long Replied by: David Roberts on 12-02-2010 04:36:43 PM 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.
Subject: RE: cause codes as integer or long Replied by: David Staudt on 12-02-2010 04:36:43 PM 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
Subject: RE: cause codes as integer or long Replied by: David Roberts on 12-02-2010 04:36:43 PM 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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
