[Home]

Summary:ASTERISK-03210: MGCP does not follow correct call flow when going off-hook
Reporter:duanecox (duanecox)Labels:
Date Opened:2005-01-08 10:14:04.000-0600Date Closed:2011-06-07 14:04:44
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When going off-hook, the function "handle_hd_hf" in Asterisk MGCP is currently programmed to first start the RTP via a CRCX connection, then second activate dialtone by sending a RQNT.

While this obviously works for most MGCP GW's out there (or someone else would have submitted a bug by now) I believe this procedure is out of order, and for Asterisk to be correct, it would first send the RQNT to generate dialtone or studder-dialtone, then send the CRCX to bring up the RTP.

I base this bug on call flow example in the RFC 3435 Appendix G.2, as well as a discovery of a GW that follows a VERY strick MGCP implementation.  When these out of order MGCP commands are processed, this GW shuts down the RTP that was established via the CRCX when it receives the RQNT.

I have discussed my CRCX/RTP problem with Mark in general.  At the time of our discussion, I was not aware that it was the result of this processing problem.  After some time and experimenting in Asterisk, I was able to get the rtp to startup with the CRCX command as seen in the calltrace.  But RTP will soon die with the GW processes the unexpected RQNT command.

I marked this as a MAJOR bug due to the fact that (I believe) this violates the RFC and is a significant protocol violation.


****** ADDITIONAL INFORMATION ******

For a detailed call flow example SEE RFC 3435 Appendix G.2


An example of my GW problem:

MGCP read:  
ntfy 1706 aaln/1@[10.252.229.29] MGCP 1.0
X: 0
O: hd

from 10.252.229.29:2427
Verb: 'ntfy', Identifier: '1706', Endpoint: 'aaln/1@[10.252.229.29]', Version: 'MGCP 1.0'
3 headers, 0 lines
Handling request 'ntfy' on aaln/1@10.252.229.29
Transmitting:
200 1706 OK

to 10.252.229.29:2427
   -- Endpoint 'aaln/1@10.252.229.29-1' observed 'hd'
   -- Creating connection for aaln/1@10.252.229.29-1 in cxmode: sendrecv callid: 058270ce4e6afb66
We're at 10.252.229.18 port 7918
Answering with capability 4
Posting Request:
CRCX 4 aaln/1@[10.252.229.29] MGCP 1.0
C: 058270ce4e6afb66
L: p:20, a:PCMU
X: 4e6afb66
M: sendrecv
R: hu,hf(I)

v=0
c=IN IP4 10.252.229.18
m=audio 7918 RTP/AVP 0
to 10.252.229.29:2427
   -- MGCP Asked to indicate tone: L/dl on  aaln/1@10.252.229.29-1 in cxmode: sendrecv
Posting Request:
RQNT 5 aaln/1@[10.252.229.29] MGCP 1.0
X: 41a7c4c9
R: L/hu(N),L/hf(N)
S: L/dl
to 10.252.229.29:2427
   -- MGCP mgcp_new(MGCP/aaln/1@10.252.229.29-1) created in state: Down
MGCP read:  
200 4 OK
I: 0001E0CE40

v=0
c=IN IP4 10.252.229.29
m=audio 10000 RTP/AVP 0

from 10.252.229.29:2427
Verb: '200', Identifier: '4', Endpoint: 'OK', Version: '(null)'
2 headers, 3 lines
Capabilities: us - 4, them - 4, combined - 4
Non-codec capabilities: us - 1, them - 0, combined - 0
Got RTP packet from 10.252.229.29:10000 (type 0, seq 0, ts 48580, len 80)
Got RTP packet from 10.252.229.29:10000 (type 0, seq 1, ts 48660, len 80)
Got RTP packet from 10.252.229.29:10000 (type 0, seq 2, ts 48740, len 80)
Got RTP packet from 10.252.229.29:10000 (type 0, seq 3, ts 48820, len 80)
Got RTP packet from 10.252.229.29:10000 (type 0, seq 4, ts 48900, len 80)
Got RTP packet from 10.252.229.29:10000 (type 0, seq 5, ts 48980, len 80)
Got RTP packet from 10.252.229.29:10000 (type 0, seq 6, ts 49060, len 80)
Got RTP packet from 10.252.229.29:10000 (type 0, seq 7, ts 49140, len 80)
Got RTP packet from 10.252.229.29:10000 (type 0, seq 8, ts 49220, len 80)
Got RTP packet from 10.252.229.29:10000 (type 0, seq 9, ts 49300, len 80)
Got RTP packet from 10.252.229.29:10000 (type 0, seq 10, ts 49380, len 80)
Got RTP packet from 10.252.229.29:10000 (type 0, seq 11, ts 49460, len 80)
MGCP read:  
200 5 OK

from 10.252.229.29:2427
Verb: '200', Identifier: '5', Endpoint: 'OK', Version: '(null)'
1 headers, 0 lines
devel1*CLI>
devel1*CLI>

RTP NOW DEAD WHEN GW PROCESSED OR RESPONDED TO RQNT
Comments:By: Mark Spencer (markster) 2005-01-08 10:27:15.000-0600

This is not a bug unless you have something within the RFC which states that this is not possible to do.  It is important to send the CRCX immediately in order that devices which do not support out of band signalling can immediately begin transmitting audio.

Just because your device does not like this sequence does not make it a bug.  Only having something in the RFC which states "You MUST NOT send CRCX" or whatever would be acceptable.
By: duanecox (duanecox) 2005-01-08 10:34:34.000-0600

A note about the fix for this problem:

After going off-hook, Asterisk should send the RQNT to indicate dialtone, but it should also wait for the 200 OK before it sends the following CRCX command.

According to the RFC, Asterisk should not send these commands back to back without first getting back a 200 OK.  If the first command (RQNT) fails for whatever reason, Asterisk should not send the CRCX.
By: Russell Bryant (russell) 2005-01-08 16:01:24.000-0600

Re-open with a direct quote from the RFC if you feel that we aren't compliant.