[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

[Matt Jordan]

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

Ship it!


Shipping, as the two issues mentioned below are trivial.


/asterisk/trunk/tests/fax/directmedia_reinvite_t38/sipp/inject_bridge.csv
<https://reviewboard.asterisk.org/r/2854/#comment18943>

    If you can, put a new line at the end of this file. Some text editors will thank you.
    
    (If this causes problems for SIPp, then feel free to disregard)



/asterisk/trunk/tests/fax/directmedia_reinvite_t38/test-config.yaml
<https://reviewboard.asterisk.org/r/2854/#comment18942>

    This should be a tag of "fax" (that is, lowercase 'f').
    
    If you're ever wondering what tags you should use, using the "-L" option with runtests will dump out the current selection of tags. Preference should be given to tags that already exist, as opposed to create new ones.


- Matt Jordan


On Sept. 20, 2013, 5:47 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2854/
> -----------------------------------------------------------
> 
> (Updated Sept. 20, 2013, 5:47 p.m.)
> 
> 
> 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/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/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/20130923/5f4616a3/attachment.htm>