Help!(MGCP topics)Why asterisk send DLCX to me

Asterisk Asterisk Support
#1

I use aterisk1.4.20. My app simulate mediagateway.
In one bad call:

  1. I send NOTIFY and CRCX, it’s OK.
  2. Then aterisk send me 8 times of RQNT.
  3. The aterisk send me 2 consecutive MDCX, then followed RQNT, when I respond this last RQNT with 200 OK, The aterisk send me a DLCX immediately to discconect. I don’t know why and the call is not begin at all.
    All response to commands is the same as the correct call except that the command sequence:
    In one good call:
  4. I send NOTIFY and CRCX, it’s OK.
  5. Then aterisk send me 10 times of RQNT, the last one with X: 073f416f, R: L/hu(N),L/hf(N),D/0-9#*, S: G/rt
  6. Then aterisk send me MDCX+RQNT+MDCX, then the rtp data begin to transfer and all is good later.
    In bad calls, the RQNT with S: G/rt didn’t reveived before the MDCX, I’m not sure if this is why the aterisk send me the DLCX, and I’m also not sure if all the those RQNTs between CRCX and MDCX are indispensible to call agent(asterisk). Can anyone help me? Thanks a lot.
    The folloing is the bad call log for your reference. I had 2 bad calls, one is RQNT with S: G/rt was delayed until after the first MDCX, the other is RQNT with S: G/rt didn’t reveived, the folowing log is the latter, all failed after the first RQNT following MDCX.
    [2011-06-26 23:49:40.423546:gmt INF VOVIDA_MGC RTP 8.11.1.33] send:
    NTFY 146423 aaln/7@[10.10.9.15] MGCP 1.0
    O: L/hd
    X: 32db9ca4

[2011-06-26 23:49:40.424340:gmt INF MGCP RTP 8.11.1.33] Incoming Request:
CRCX 559973 aaln/7@[10.10.9.15] MGCP 1.0
C: 5b292fa7687df34e
L: p:20, a:PCMU
M: sendrecv
X: 687df34e

v=0
o=root 4565 4565 IN IP4 10.10.9.82
s=session
c=IN IP4 10.10.9.82
t=0 0
m=audio 18368 RTP/AVP 0
a=rtpmap:0 PCMU/8000

[2011-06-26 23:49:40.424569:gmt INF VOVIDA_MGC RTP 8.11.1.33] send:
200 559973 OK
I: 2478

v=0
o=18298 3518120980 3518120980 IN IP4 10.10.9.15
s=session
c=IN IP4 10.10.9.15
t=3518120980 0
a=sendrecv
m=audio 5052 RTP/AVP 0
a=rtpmap:0 PCMU/8000

[2011-06-26 23:49:40.424758:gmt INF MGCP RTP 8.11.1.33] Incoming Request:
RQNT 559974 aaln/7@[10.10.9.15] MGCP 1.0
X: 32db9ca4
R: L/hu(N),L/hf(N),D/0-9#*
S: L/dl

[2011-06-26 23:49:40.424822:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
200 559974 OK

[2011-06-26 23:49:40.424893:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
NTFY 146424 aaln/7@[10.10.9.15] MGCP 1.0
O: D/1
X: 32db9ca4

[2011-06-26 23:49:40.425919:gmt INF MGCP RTP 8.11.1.33] Incoming Request:
RQNT 559975 aaln/7@[10.10.9.15] MGCP 1.0
X: 32db9ca4
R: L/hu(N),L/hf(N),D/0-9#*
S: L/dl

[2011-06-26 23:49:40.425988:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
NTFY 146425 aaln/7@[10.10.9.15] MGCP 1.0
O: D/1
X: 32db9ca4

[2011-06-26 23:49:40.426060:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
200 559975 OK

[2011-06-26 23:49:40.426775:gmt INF MGCP RTP 8.11.1.33] Incoming Request:
RQNT 559976 aaln/7@[10.10.9.15] MGCP 1.0
X: 32db9ca4
R: L/hu(N),L/hf(N),D/0-9#*
S: L/dl

[2011-06-26 23:49:40.426854:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
NTFY 146426 aaln/7@[10.10.9.15] MGCP 1.0
O: D/0
X: 32db9ca4

[2011-06-26 23:49:40.426938:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
200 559976 OK

[2011-06-26 23:49:40.427523:gmt INF MGCP RTP 8.11.1.33] Incoming Request:
RQNT 559977 aaln/7@[10.10.9.15] MGCP 1.0
X: 32db9ca4
R: L/hu(N),L/hf(N),D/0-9#*
S: L/dl

[2011-06-26 23:49:40.427618:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
NTFY 146427 aaln/7@[10.10.9.15] MGCP 1.0
O: D/0
X: 32db9ca4

[2011-06-26 23:49:40.427703:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
200 559977 OK

[2011-06-26 23:49:40.428244:gmt INF MGCP RTP 8.11.1.33] Incoming Request:
RQNT 559978 aaln/7@[10.10.9.15] MGCP 1.0
X: 32db9ca4
R: L/hu(N),L/hf(N),D/0-9#*
S: L/dl

[2011-06-26 23:49:40.428317:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
NTFY 146428 aaln/7@[10.10.9.15] MGCP 1.0
O: D/0
X: 32db9ca4

[2011-06-26 23:49:40.428388:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
200 559978 OK

[2011-06-26 23:49:40.428992:gmt INF MGCP RTP 8.11.1.33]Incoming Request:
RQNT 559979 aaln/7@[10.10.9.15] MGCP 1.0
X: 32db9ca4
R: L/hu(N),L/hf(N),D/0-9#*
S: L/dl

[2011-06-26 23:49:40.429064:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
NTFY 146429 aaln/7@[10.10.9.15] MGCP 1.0
O: D/6
X: 32db9ca4

[2011-06-26 23:49:40.429141:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
200 559979 OK

[2011-06-26 23:49:40.429740:gmt INF MGCP RTP 8.11.1.33]Incoming Request:
RQNT 559980 aaln/7@[10.10.9.15] MGCP 1.0
X: 32db9ca4
R: L/hu(N),L/hf(N),D/0-9#*
S: L/dl

[2011-06-26 23:49:40.429810:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
200 559980 OK

[2011-06-26 23:49:40.524796:gmt INF MGCP RTP 8.11.1.33] Incoming Request:
RQNT 559998 aaln/7@[10.10.9.15] MGCP 1.0
X: 32db9ca4
R: L/hu(N),L/hf(N),D/0-9#*

[2011-06-26 23:49:40.524850:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
200 559998 OK

[2011-06-26 23:49:44.524987:gmt INF MGCP RTP 8.11.1.33] Incoming Request:
MDCX 560140 aaln/7@[10.10.9.15] MGCP 1.0
C: 5b292fa7687df34e
M: sendrecv
X: 687df34e
I: 2478
R: L/hu(N),L/hf(N),D/0-9#*

[2011-06-26 23:49:44.525165:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
200 560140 OK

[2011-06-26 23:49:44.525851:gmt INF MGCP RTP 8.11.1.33] Incoming Request:
MDCX 560142 aaln/7@[10.10.9.15] MGCP 1.0
C: 5b292fa7687df34e
M: sendrecv
X: 687df34e
I: 2478
R: L/hu(N),L/hf(N),D/0-9#*

[2011-06-26 23:49:44.525974:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
200 560142 OK

[2011-06-26 23:49:46.524856:gmt INF MGCP RTP 8.11.1.33] Incoming Request:
RQNT 560000 aaln/7@[10.10.9.15] MGCP 1.0
X: 32db9ca4
R: L/hu(N),L/hf(N),D/0-9#*

[2011-06-26 23:49:46.524933:gmt INF VOVIDA_MGC RTP 8.11.1.33]send:
200 560000 OK

[2011-06-26 23:49:46.525216:gmt INF MGCP RTP 8.11.1.33]Incoming Request:
DLCX 560158 aaln/7@[10.10.9.15] MGCP 1.0
C: 5b292fa7687df34e
X: 687df34e
I: 2478

#2

Is there anyone can give me a hand? I think “S: G/rt” is optional. Does that RQNT really important?

#3

This is a rather technical question about a rarely used protocol on a forum with only about 10 regulars.

I’m not sure that this would be considered a valid developer question, but you may have more luck on the developer maling list or IRC channel. You should make sure the answer isn’t obvious from the code or comments, first.

#4

Thanks.
I looked the asterisk code on version 1.4.20 today and it seems that the DLCX is caused by sending some command fail. I only see a very high-level log under /var/log/asterisk/ , it provide me very little about the error.
I see a lot of debug lines in the code. Do you know how to turn on these logs?

#5

And what is IRC channel? Thanks!

#6

Debug will either be turned on with CLI core set debug []

or with the obvious command below:

centos*CLI> help mgcp
mgcp audit endpoint Audit specified MGCP endpoint
mgcp reload Reload MGCP configuration
mgcp set debug {on|off} Enable/Disable MGCP debugging
mgcp show endpoints List defined MGCP endpoints

IRC is a long established instant messaging protocol. For pointers to the particular one, see asterisk.org/developer/resources

#7

The log is working. Thank you, David!