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

(Updated Feb. 26, 2015, 11:35 a.m.)


Review request for Asterisk Developers.


Changes
-------

Applied the changes as suggested by Mark Michelson; made an adjustment (as 
suggested by file and mjordan on #asterisk-dev) to make the origin session id 
and version id different for re-invites.

{quote}
(2015-02-26 09:45:12) mjordan: essentially, when you modify a session, you have 
to increase the version of the session you are modifying, otherwise we have to 
assume that it is a 'stale' (or repeated) offer for an existing session
(2015-02-26 09:45:26) file: which becomes a no-op
(2015-02-26 09:45:46) mjordan: so, in your INVITE request that sends an SDP 
that takes the call "off hold", the o= line should have the <version> number 
bumped by at least one
{quote}


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


Repository: testsuite


Description
-------

This test is to ensure that Asterisk correctly applies the direction of the 
media stream when a=<sendonly|recvonly|inactive|sendrecv> is missing from the 
offer's SDP. The expected behavior is for Asterisk to apply "sendrecv" as the 
direction of the media stream when no direction attribute is present in an 
offer's SDP. According to RFC 4566 (Section 6. SDP Attributes): "If none of the 
attributes "sendonly", "recvonly", "inactive", and "sendrecv" is present, 
"sendrecv" SHOULD be assumed as the default for sessions that are not of the 
conference type "broadcast" or "H332" [...]"

The test scenario:

1. From Phone A, send an offer to Phone B to establish a call
2. From Phone B, send an offer to Phone A to put the call on hold. 
3. Observe that the MOH start event occurs.
4. From Phone B, send an offer to Phone A to 'un-hold' the call (ensure that 
the direction attribute from the offer's SDP is omitted)
5. Observe that the MOH stop event occurs.

Presently, this test fails for certain versions of Asterisk. From what I can 
tell, it is present from (at least) 1.8.21 up to the 11 branch.

***Note*** This is the test. It is only the test. The update to the Asterisk 
source is coming soon to a review board near you (well, this review board).


Diffs (updated)
-----

  ./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_B_no_direction.xml 
PRE-CREATION 
  ./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_B_media_restrict.xml 
6458 
  ./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_B_IP_restrict.xml 
6458 
  
./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_B_IP_media_restrict.xml 
6458 
  ./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_A_no_direction.xml 
PRE-CREATION 
  ./asterisk/trunk/tests/channels/SIP/sip_hold/run-test 6458 

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


Testing
-------


Thanks,

Ashley Sanders

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to