[Home]

Summary:ASTERISK-19053: Investigate why the gateway_mix2 test is failing.
Reporter:Matthew Nicholson (mnicholson)Labels:
Date Opened:2011-12-15 09:23:44.000-0600Date Closed:2012-01-17 17:15:18.000-0600
Priority:BlockerRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/T.38 Resources/res_rtp_asterisk
Versions:10.0.0 Frequency of
Occurrence
Related
Issues:
must be completed before resolvingASTERISK-19041 Asterisk 10.1.0 Blockers
must be completed before resolvingASTERISK-19129 Asterisk 10.2.0 Blockers
Environment:Attachments:( 0) gateway_mix2_bad.pcap
( 1) gateway_mix2_working.zip
( 2) working1.pcap
Description:I think I know why this is failing, although I can't explain why it works on my test machine but not in the testsuite. The test is supposed to test the case when T.38 negotiation fails and the fax gateway removes itself from the channel. This part appears to work, but after the T.38 negotiation fails, ast1 starts rejecting RTP traffic from ast2 with the following messages:

{noformat}
[Dec 15 00:51:20] DEBUG[12839] res_rtp_asterisk.c: Received RTP packet from 127.0.0.1:10192, dropping due to strict RTP protection. Expected it to be from 127.0.0.2:12748
[Dec 15 00:51:20] DEBUG[12838] res_rtp_asterisk.c: Received RTP packet from 127.0.0.1:16290, dropping due to strict RTP protection. Expected it to be from 127.0.0.2:13162
{noformat}

It appears that the sending ports may have changed somewhere. If this is a bug then it is related to our rtp code or our sip code and probably not any of the fax code.

For reference, the test description is as follows:
{noformat}
This test verifies proper gateway functionality when a v21 triggered
t38 negotiation request fails and the receiving side does not support
t38. The gateway should detect the failed reinvite and disable itself.

The call flow looks like this:
|send        |
|g711     t38|
|----------->|
|     gateway|
|g711    g711|
|<-----------|
\|receive     |/

{noformat}
Comments:By: Matthew Nicholson (mnicholson) 2011-12-15 09:53:45.507-0600

I am attaching a pcap and logs from this test on my working system. The logs are labeled ast3-full.txt and ast4-full.txt (which correspond to ast1/var/log/asterisk/full.txt and ast2/var/log/asterisk/full.txt in the test artifacts for this test).

In the pcap, asterisk appears to be sending a lot of reinvites back and forth. I am not sure if that is the proper behavior or not.
By: Matthew Nicholson (mnicholson) 2011-12-15 09:55:26.489-0600

If all else fails, setting strictrtp=no in rtp.conf for this test will probably work around the problem although I don't think that is the right fix here.
By: Kinsey Moore (kmoore) 2012-01-16 14:36:18.660-0600

Now that I've gotten a trace of the failing scenario, I have verified that it is strictrtp that is failing and not something more serious.  Conveniently, JRose has a patch on reviewboard that fixes this problem which can be found here: https://reviewboard.asterisk.org/r/1663/
By: Kinsey Moore (kmoore) 2012-01-17 10:24:01.245-0600

Attached "failing" case.  The related logs are nearly identical to other failures (just the port numbers change).  This is a failing of strictrtp that is corrected by jrose's patch.  I went through the RTP by hand and verified that everything seems to be in order.
By: Kinsey Moore (kmoore) 2012-01-17 17:15:18.235-0600

Closing since jrose's strictrtp fix is committed