[asterisk-dev] [Code Review] 2854: testsuite: Test that T.38 Reinvites have the image contact in SDP set to the address of Asterisk rather than the addresses of the opposite peer

[jrose]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2854/
-----------------------------------------------------------

Review request for Asterisk Developers, Joshua Colp and Mark Michelson.


Bugs: ASTERISK-17273
    https://issues.asterisk.org/jira/browse/ASTERISK-17273


Repository: testsuite


Description
-------

This test compliments https://reviewboard.asterisk.org/r/2853/

The idea is basically to set up a direct media call between two devices and then have one device send a fresh invite which changes the media to an image to start a T38 session similar to how the transactions went in ASTERISK-17273. The framework for this test is basically recycled from the SIP/sip_hold tests, but it's stripped down for this purpose.

Without the patch from https://reviewboard.asterisk.org/r/2853/ applied, this test fails because the T.38 reinvite includes only the opposite peer in its SDP contact. With the patch applied, it passes because Asterisk's address is included as well. Investigation of the logs shows that the opposite peer address is included as well, but for the image portion, a second C=127.0.0.1 IN IPV4 is included as well, so that should solve the situation according to Mark.

WARNING: This test relies on currently dangerous SIPp stuff which needs to be fixed. Similar to sip_hold and originate-cdr-disposition, if this test fails under certain conditions it's possible for SIPp processes to remain open and confound later tests ran producing failures. A separate patch should probably be made to kill all SIPP processes on startup of a new test at some point.


Diffs
-----

  /asterisk/trunk/tests/fax/directmedia_reinvite_t38/configs/ast1/extensions.conf PRE-CREATION 
  /asterisk/trunk/tests/fax/directmedia_reinvite_t38/configs/ast1/sip.conf PRE-CREATION 
  /asterisk/trunk/tests/fax/directmedia_reinvite_t38/run-test PRE-CREATION 
  /asterisk/trunk/tests/fax/directmedia_reinvite_t38/sipp/endpoint_A.xml PRE-CREATION 
  /asterisk/trunk/tests/fax/directmedia_reinvite_t38/sipp/endpoint_B.xml PRE-CREATION 
  /asterisk/trunk/tests/fax/directmedia_reinvite_t38/sipp/inject_bridge.csv PRE-CREATION 
  /asterisk/trunk/tests/fax/directmedia_reinvite_t38/sipp/inject_bypass.csv PRE-CREATION 
  /asterisk/trunk/tests/fax/directmedia_reinvite_t38/test-config.yaml PRE-CREATION 
  /asterisk/trunk/tests/fax/tests.yaml 4136 

Diff: https://reviewboard.asterisk.org/r/2854/diff/


Testing
-------

Ran the test with and without the patch from https://reviewboard.asterisk.org/r/2853/ and checked how the SIP messages looked compared to what I would expect. This also is a test.


Thanks,

jrose

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130913/aae6ff36/attachment-0001.htm>