Uniqueid identified in two different timestamp

Asterisk Asterisk Support
1

Hi,

I have the following issue :

“”,“374091241”,“send”,“fax-tx”,“374091241”,“DAHDI/49-1”,"",“AGI”,“agi:async”,“2015-11-13 05:20:08”,“2015-11-13 05:20:36”,“2015-11-13 05:21:27”,79,51,“ANSWERED”,“DOCUMENTATION”,“1447392008.94114”,""

07:20:08,045 INFO [ro.radcom.email2fax.core.sm.FaxOutboundStateMachine] (Asterisk-Java ManagerConnection-0-Reader-0) RESPONSE CHANNEL EVENT FOR IMSI 226109900362409, CDR_EMAIL2FAX_OUTBOUND 1967299, CHANNEL DAHDI/49-1 ; 1447392008.94114 ; 49.
“CHAN_START”,“2015-11-13 07:20:08.045”,"","","","","",“s”,“dahdi-orange”,“DAHDI/49-1”,"","",“3”,"",“1447392008.94114”,“1447392008.94114”,"","",""
“ANSWER”,“2015-11-13 07:20:36.295”,"",“374091241”,“374091241”,"","",“s”,“dahdi-orange”,“DAHDI/49-1”,"","",“3”,"",“1447392008.94114”,“1447392008.94114”,"","",""

I use the unique_id as a reference in my call-control (own java development for fax transaction), but I have two calls on a different time period with the same unique_id :
CALL 1 at moment 2015-11-13 05:20:36 with unique_id 1447392008.94114.
CALL 2 at moment 2015-11-13 07:20:08.04 with same unique_id 1447392008.94114.

Can some help to understand why i have two calls with the same unique_id ? in condition that the call have a timestamp of approximately 2 hours ? From what I know is that the unique_id is uniqe.

Asterisk version 1.8.28-cert5 ;

Best Regards,
George Sand

2

Because both relate to the same channel. The unique-ID is an identifier for the channel data structure. In simple cases, it tracks with the channel name, but the way that Asterisk handles more complex operations like transfers, parking, optimisation out of local channels, etc., is that it replaces or swaps (all such operations actually involve a swap, but sometimes it is a swap with a newly created structure) the channel data structures, whilst moving the technology dependent data structure, and the channel name between them. This is known as masquerading. The unique-ID allows external programs to track the actual data structure, independent of its name.

They are not intended to be used as database primary keys for call detail records.

3

Hi,

The issue is not related to the masquerad, if that id has the comportment that you describe it has to apply to all the channels in the Asterisk platform.

For the example : DAHDI/55-1 , has generated uniqueu id different :

“”,“374097714”,“send”,“fax-tx”,“374097714”,“DAHDI/55-1”,"",“Dial”,“DAHDI/r11/N256379800”,“2015-11-13 05:22:04”,“2015-11-13 05:22:04”,0,0,“NO ANSWER”,“DOCUMENTATION”,“1447392121.94122”,""

“”,“374097715”,“send”,“fax-tx”,“374097715”,“DAHDI/55-1”,"",“SendFAX”,"/fax/docs/email2fax/pdf/send/348/1323134_dest246278422_cont1.tiff",“2015-11-13 05:25:54”,“2015-11-13 05:26:05”,“2015-11-13 05:27:24”,90,79,“ANSWERED”,“DOCUMENTATION”,“1447392354.94247”,""

From my point of view I think in the state machine on the Asterisk (still searching to identify the correct class or classes) the reference for the variable unique_id after the malloc(C language specification) allocation is not calling the free(C language specification) method synchronously.

Also the unique_id format is a timestamp format (UNIX defined), I really don’t understand how the unique id name is generated from the channel name. I don’t keep the unique id as an id reference in the table, I only keep the unique_id as a reference for all the events received from the Asterisk for each channel bind to that unique_id.

Best Regards,
George Sand

4

free() is irrelevant to unique IDs. The unique ID is the time at which the channel structure was created concatenated with a global serial number (although you should not rely on this).

The only way that the same channel name would be associated with two different unique IDs is if there has been a masquerade, but I’d need details of your dialplan, and any AMI operations performed to work out why there has been a masquerade.

5

Hi

you can find the following configuration in the dialplan , extension.conf :

[general]
static=yes
writeprotect=yes
autofallthrough=yes
extenpatternmatchnew=yes
clearglobalvars=yes
userscontext=user-default

[globals]
CONSOLE=Console/dsp
ORO1=DAHDI/G2
FAXCOUNT=1

[sip-default]
exten => _X.,1,NoOp()
exten => _X.,n,Hangup()

exten => i,1,NoOp()
exten => i,n,Hangup()

exten => h,1,NoOp()
exten => h,n,Hangup()

[sip-reg-intern]
exten => _X.,1,NoOp()
exten => _X.,n,Hangup()

exten => i,1,NoOp()
exten => i,n,Hangup()

exten => h,1,NoOp()
exten => h,n,Hangup()

[sip-subscr-intern]
exten => _X.,1,NoOp()
exten => _X.,n,Hangup()

exten => i,1,NoOp()
exten => i,n,Hangup()

exten => h,1,NoOp()
exten => h,n,Hangup()

;incoming context
[dahdi-xxxx]

exten => _bX.,1,NoOp()
exten => _bX.,n,Goto(fax-rx,${CALLERID(dnid):0:2}0${CALLERID(dnid):2},1)
;exten => 374091431,n,Hangup()

exten => i,1,NoOp()
exten => i,n,Hangup()

exten => h,1,NoOp()
exten => h,n,Hangup()

[fax-rx]
exten => _bX.,1,NoOp()
exten => _bX.,n,Set(CHANNEL(language)=ro)
exten => _bX.,n(agi),NoOp()
exten => _bX.,n,AGI(agi:async)
exten => _bX.,n,Goto(agi)
exten => _bX.,n,Goto(agi)

exten => i,1,NoOp()
exten => i,n,Hangup()

exten => h,1,NoOp()
exten => h,n,Hangup()

[fax-tx]
exten => send,1,NoOp()
exten => send,n,Set(CHANNEL(language)=ro)
exten => send,n(agi),NoOp()
exten => send,n,AGI(agi:async)
exten => send,n,Goto(agi)
exten => send,n,Goto(agi)
exten => send,n,Goto(agi)
exten => send,n,Goto(agi)

exten => i,1,NoOp()
exten => i,n,Hangup()

exten => h,1,NoOp()

The action that I send over ami are OriginateAction, Answer, SendFax, ReceiveFax, Hangup.

The ami configuration if is manage.conf :
[general]
enabled = yes

port = 5038
bindaddr = 0.0.0.0

displayconnects = yes
timestampevents = yes

authtimeout = 30
authlimit = 50

[admin]
secret = XXXX
permit=127.0.0.1/255.255.255.0

displayconnects = yes

read = system,call,log,verbose,agent,user,config,dtmf,reporting,cdr,dialplan,agi,cc,aoc
write = system,call,agent,user,config,command,reporting,originate,agi,aoc

Best regards,
George Sand

6

The last example is for two completely different channels. It looks like dahdi channel instance names are limited to being 1, 2, or 3, because it doesn’t need more given that it is circuit switched.

Dahdi has confusing usage of the term channel. For most purposes in Asterisk, a channel represents an active call leg, but for Dahdi it can also mean a particular piece of wire or a particular time slot on a piece of wire or fibre. The channels in CDRs are strictly the former, but the name is composed from the name of the latter, with a suffix.

For something like SIP, that can support arbitrary numbers of concurrent channels, a quite long instance identifier is appended to the basic address.

Given that the association between channel name and unique ID can change in a masquerade, that does mean that there is no completely reliable identifier for a technology channel that is unique after the end of the call.