MGCP channel mix-up with ADIT 600


A strange problem while I ring MGCP channel on an ADIT 600: it rings OK, but when the call is replied, a second FXS line is connected to the channel. The dial tone from the second line is heard over the channel; after a time-out there is fast busy, and no any tone at the end, but the second line stays connected till the call is closed.

The line in the log below " MGCP mgcp_new(MGCP/aaln12@10.69…" tells that FXS line 12 has been connected to the channel, and the line shows amber ligt on the ADIT, so it is open. There is no reason for line 12 to open - I dial line 1 (aaln/1), as shown.

Some one with an idea what is happening? Why line 12? I did change two computers, did reinstall asterisk few times, and it persists.

Configuration: Stock asterisk Asterisk from Debian Wheezy on HP DL380 G3; also same asterisk version on Neoware E140 with Debian squeeze, same situation.


// Trunk entry from voipms-01
context TRUNK-IN {
5143168452 => { Answer(); Dial(MGCP/aaln/1@; Hangup(); }

Asterisk trace:
== Using SIP RTP CoS mark 5
– Executing [5143168452@TRUNK-IN:1] Answer(“SIP/voipms-01-00000006”, “”) in new stack
– Executing [5143168452@TRUNK-IN:2] Dial(“SIP/voipms-01-00000006”, “MGCP/aaln/1@”) in new stack
– MGCP mgcp_request(aaln/1@
– MGCP cw: 0, dnd: 0, so: 0, sno: 0
– MGCP mgcp_new(MGCP/aaln/1@ created in state: Down
– Called MGCP/aaln/1@
– MGCP/aaln/1@ is ringing
[color=#FF0000]-- MGCP mgcp_new(MGCP/aaln/12@ created in state: Down [/color] <<<<< Why is line 12 opened ???
– MGCP/aaln/1@ answered SIP/voipms-01-00000006
– Executing [h@TRUNK-IN:1] Hangup(“SIP/voipms-01-00000006”, “”) in new stack
== Spawn extension (TRUNK-IN, h, 1) exited non-zero on ‘SIP/voipms-01-00000006’
– MGCP handle_request(aaln/12@ ast_channel already destroyed, resending DLCX.
– MGCP handle_request(aaln/12@ set vmwi(-)
== Spawn extension (TRUNK-IN, 5143168452, 2) exited non-zero on ‘SIP/voipms-01-00000006’


port = 2427
bindaddr =

; See qos.tex or Quality of Service section of asterisk.pdf for a description of these parameters.
;tos=cs3 ; Sets TOS for signaling packets.
;tos_audio=ef ; Sets TOS for RTP audio packets.
;cos=3 ; Sets 802.1p priority for signaling packets.
;cos_audio=5 ; Sets 802.1p priority for RTP audio packets.

;------------------------------ JITTER BUFFER CONFIGURATION --------------------------
jbenable = yes ; Enables the use of a jitterbuffer on the receiving side of a
jbforce = no ; Forces the use of a jitterbuffer on the receive side of a MGCP
jbmaxsize = 200 ; Max length of the jitterbuffer in milliseconds.
jbresyncthreshold = 1000 ; Jump in the frame timestamps over which the jitterbuffer is
jbimpl = fixed ; Jitterbuffer implementation, used on the receiving side of a MGCP
jbtargetextra = 40 ; This option only affects the jb when ‘jbimpl = adaptive’ is set.
jblog = no ; Enables jitterbuffer frame logging. Defaults to “no”.
;; The MGCP channel supports the following service codes:
;; # - Transfer
;; *67 - Calling Number Delivery Blocking
;; *70 - Cancel Call Waiting
;; *72 - Call Forwarding Activation
;; *73 - Call Forwarding Deactivation
;; *78 - Do Not Disturb Activation
;; *79 - Do Not Disturb Deactivation
;; *8 - Call pick-up

canreinvite = no
threewaycalling = no
cancallforward = no
transfer = no
callwaiting = no
;wcardep = aaln/*
slowsequence = yes

line = aaln/1
line = aaln/2
line = aaln/3
line = aaln/4
line = aaln/5
line = aaln/6
line = aaln/7
line = aaln/8
line = aaln/9
line = aaln/10
line = aaln/11
line = aaln/12
line = aaln/13
line = aaln/14
line = aaln/15
line = aaln/16
line = aaln/17
line = aaln/18
line = aaln/19
line = aaln/20
line = aaln/21
line = aaln/22
line = aaln/23
line = aaln/24
line = aaln/25
line = aaln/26
line = aaln/27
line = aaln/28
line = aaln/29
line = aaln/30
line = aaln/31
line = aaln/32
line = aaln/33
line = aaln/34
line = aaln/35
line = aaln/36
line = aaln/37
line = aaln/38
line = aaln/39
line = aaln/40

Well, it took to write this message, (and a day and half of wandering) to find the bug: a wiring fault on the FXS lines side. Some wires were misplaced, and there was an electrical contact between lines 1 and 12, what made the line 1 to ring, but not line 12; when the line 1 was replied, the ADIT did signal the line 12 as open. Quite a strange situation, and I fear I can not replicate it if needed for tests…

Anyway, resolved, this ADIT is functional now. Sorry for the noise - George.