A collection of test scenarios for osmo-msc
===========================================

1) Fuzzy M3UA
* Restart STP multiple times in a row, then test connectivity (e.g. by executing
  an A-Interface transaction that requires making an SCCP connection
* Silently vanish while performing an operation (e.g. shut down M3UA while
  doing a location update, call, sms etc...)


2) Fuzzy SCCP
* Make an SCCP connection and leave the connection open (Will the MSC close it?)
* Make an SCCP connection perform some action (e.g. LU) but do not send a clear
  command, see if the MSC closes the connection.
* Send garbeled connection less SCCP packet
* Send garbeled connection less SCCP packet but with correct BSSMAP header
* Make SCCP connection, send garbeled packet
* Make SCCP connection, Send garbeled packet but with correct BSSMAP header
* Make SCCP connection, Send garbeled packet but with correct DTAP header
* Make SCCP connection and send an early clear command (this should could
  be done with all operations to see if this behaviour results in uncleared
  state)
* Make an SCCP connection, perform an action but do not respond to the clear
  command at the end. Do we still release the connection gracefully?


3) Fuzzy BSSAP
* Make an SCCP connection with a CM Service Request, but request a service that
  does not exist.
* Perform the same action concurrently (e.g. the same location update for the
  same subscriber at the same time, try also with calls and SMS).


4) Reset
* Send a BSSMAP RESET, check if responded with BSSMAP RESET ACK in time
* Repeat Reset procedure multiple times in a row
* Send another reset before MSSMAP RESET ACK is received (fast series of BSSMAP
  RESET)


5) Location update
* Perform a normal location update
* Perform a location update but use wrong Ki (should be rejected)
* Perform a location update but leave out TMSI Reallocation Complete message
* Perform a location update but don't respond to Cipher mode command
* Perform a location update that gets rejected, but send a TMSI Reallocation
  Complete anyway.


6) MO-Call
* Make a call (normal)
* Hard-close the SCCP connection while a call is running by sending a clear
  command
* Make a call, but do not acknowledge the connection (Connect Acknowledge)
* See what happens when using wrong KI (call should fail)
* Stop after the Cipher Mode Complete message, do not send Setup. Do we run in a
  timeout and clear the sccp connection?
* Leave out CALL Proceeding message.
* Leave out Connect message
* Do not respond to any MGCP request (MGW down)
* Fail every MGCP request
* Fail one choosen MGCP transaction. Repeat this test until all MGCP
  transactions have been tried.
* Stop responding to one choosen MGCP transaction. Repeat this test until all
  MGCP transactions have been tried.  
* Check if the RTP streams are properly switched, do the RTP parameters issued
  by the MSC make sense?
* Respond with garbeled MGCP messages, see what happens when the IP-Address
  is an empty string or is missing completely. Also check the same with the
  other parameters.
* Try what happens when the MGW returns the same connection identifier for both
  connections.
* Make a call, but in the ASSIGNMENT COMPLETE message, respond with a choosen
  codec that was not on the speech codec list in the ASSIGNMENT REQUEST.


7) MT-Call
(Where possible, apply the odd cases from MO-Call)
* Place a call via MNCC (normal)
* Do not respond to paging
* Respond with a wrong IMSI in PAGING RESPONSE
* Miss out the ALERTING message


8) MO-SMS
* Send an SM (normal)
* Stop after the Cipher Mode Complete message, do we run in a timeout and clear
  the sccp connection?
* Skip CP-DATA/RP-DATA, just send an unsoliciated CP-ACK
* Send CP-DATA/RP-DATA twice
* Leave out TP-Destination-Address in CP-DATA/RP-DATA
* Use an invalid TP-PID in CP-DATA/RP-DATA.
* Use an invalid TP-DCS in CP-DATA/RP-DATA.
* Try coding groups other than GSM 7 bit default alphabet (do we support
  different ones?)
* Can TP-User-Data-Length exceed the allowed 160 chars? If yes we should try
  what happens when we exceed this limit.
* Try with message that has exactly 160 chars (maximum length)


9) MT-SMS
* Initiate sending an SM via GSUP
* Skip the CP-ACK message.
* Skip the CP-DATA/RP-ACK message.
* Respond with DTAP/MSMS/CP-ERROR, see if the MSC trys to deliver the SM again.


10) USSD
* Execute USSD request (*#100#) normally
* Use invalid ussd-DataCodingScheme parameter
* Try USSD string that exceeds the maximum permitted length
* Try USSD string that has exactly the maximum permitted length
* Try coding groups other than GSM 7 bit default alphabet (do we support
  different ones?)
* Try strings that violate the common USSD syntax (*/#)


11) External handover
(This case requires two BSC/MGW test components)
* Run external handover procedure as normal.
* Run the procedure again, stop responding to MSC messages where possible to
  see if timeout mechanisms (T23) work properly.
* For HANDOVER REQUIRED try the procedure with the invalid changes:
  * Use invalid cause code in HANDOVER REQUIRED message
  * Send an empty Cell Identifier List
  * Send no Cell Identifier List
  * Choose channel type other than SPEECH (currently we only support SPEECH)
  * Send not speech version
  * Send no AoIP speech codec.
  (The MSC should recject the HANDOVER REQUIRED message with an
  HANDOVER REQUIRED REJECT message, check if the cause code set by the MSC
  makes sense)
* For HANDOVER REQUEST ACKNOWLEDGE try the procedure with the invalid changes:
  * Send no Layer 3 information
  * Send no AoIP Transport Layer Address
  * Send port number = 0 in AoIP Transport Layer Address
  * Send IP-Address 0.0.0.0 in AoIP Transport Layer Address
  * Send no Codec List
  * Send inconsistant Codec List
  * Send no Speech Version
  * Send no Speech Codec
   (The MSC should send an HANDOVER REQUIRED REJECT to the source BSC? Does the
   cause code make sense?)
* Answer the HANDOVER REQUEST message directly with an HANDOVER FAILURE message,
  the MSC should then HANDOVER REQUIRED REJECT to the source BSC (correct?)
* Skip HANDOVER DETECT and directly send HANDOVER COMPLETE message