Sendrecv mode flag controls whether the sendrecv
state is forced to sendrecv, instead of the default
one sendonly, in the SDP body going towards recipient
(the one who will receive the MoH media).
Is declared as: moh=[mode=sendrecv]
Can be useful for corner cases, where the remote side
wants to see sendrecv state for whatever reason,
when getting MoH media and hence also remain in sendrecv
state in regards of the MoH originator.
Must be advertised once during the session origination,
nd then will affect the SDP body as soon as SDP sendonly
body is received (from the behalf of one, who advertised MoH
capabilities).
Backwards compatibility: doesn't affect non-MoH calls.
And doesn't affect offer/answer exchanges within MoH calls,
which do not put the remote side on hold.
Additionally: introduce a common function for the MoH flags
handling: `call_ml_moh_handle_flags()`, which does all
the required iterations/checks for the whole bunch of flags
at once.
Additionally: previously existing MoH tests adopted.
Additionally: new test introduced to check the SDP content,
when using mode sendrecv flag.
Remark: this flag is not mutually exclusive with
the zero-connection MoH flag.
Change-Id: I5bf6699f6890d8b927107cc143a18116efe45087
offer('Music on hold - sendrecv and declared zero-connection',{ICE=>'remove',DTLS=>'off',moh=>{blob=>$wav_file,connection=>'zero',mode=>'sendrecv'}},<<SDP);
offer('Music on hold - sendrecv and declared zero-connection',{ICE=>'remove',DTLS=>'off',moh=>{blob=>$wav_file,connection=>'zero'}},<<SDP);
v=0
o=-15459970271INIP4198.51.100.1
s=tester
@ -26384,7 +26384,7 @@ a=rtcp:PORT
SDP
# declare that answerer is capable of moh (fake db-id)
answer('Music on hold - sendrecv and declared zero-connection',{ICE=>'remove',moh=>{'db-id'=>'123',connection=>'zero',mode=>'sendrecv'}},<<SDP);
answer('Music on hold - sendrecv and declared zero-connection',{ICE=>'remove',moh=>{'db-id'=>'123',connection=>'zero'}},<<SDP);