TFM Message Expect Actions
TFM actions are concrete test actions derived from Action. See Resip TFM. Each concrete action acts as a memento; the actual exectution of the action is delayed until triggered by the TFM Implementation#Intepreter
- 1 ReInvite
- 2 Subscribe
- 3 SipEndPointAction
- 4 ExpectAction
- 4.1 InviteReferReplaces
- 4.2 Retransmit
- 4.3 MessageExpectAction
- 4.3.1 Macros
- 184.108.40.206 EXPECT_FUNCTOR
- 220.127.116.11 EXPECT_FUNCTOR_RESPONSE
- 18.104.22.168 EXPECT_FUNCTOR_TARGETED
- 4.3.2 RawReply
- 4.3.3 Send302
- 4.3.1 Macros
- 5 MessageAction
Accessed with the reInvite method on TestSipEndPoint. Creates an INVITE message within an existing INVITE dialog. Throws if there is no existing INVITE dialog -- the throw will cause the test to fail.
Accessed with the subscribe method on TestSipEndPoint. Creates and sends a SUBSCRIBE message. There are several interfaces for specifying the request Url (the document of interest).
Overrides the operator() and delegates message creation to the virtual method go. This hides message sending and more importantly, allows the geneneric application of message conditioners before the message is sent. See Resip TFM#Message Conditioners.
Most of the derived MessageExpectActions are declared via macro
Declares an Action triggered by a SIP message. The TetsSipEndPoint involved is available to the action's function.
This is a debugging aid. The triggering message is logged.
Used through out sanityTests.cxx for INVITE transactions. Creates the request in dialog for successes. Returns the ACK for sendinf in INVITE success and failure cases.
Not used. Not defined!?
Creates the BYE message in dialog.
Creates the CANCEL message against the sent INVITE (note that TestSipEndPoint assumes a single simultaneous INVITE session per endpoint).
Creates the NOTIFY/200 response in the appropriate dialog, as determined by target.
Declares an Action triggered by a SIP message. The action's function is defined to respond with a SIP response with the configured response code. If there is a dialog, the response is sent in dialog. Each action can be accessed by a method on TestSipEndPoint of similar name. For example, Ring is created with a call to the method ring.
Most of this class of actions is better replaced with a generic send response action. E.g. send(403). Some of them have semantic content identifiable beyond the specific response code carried and are helpful, for exameple, ring, and ok. Arguably, each of these should take an optional reponse code parameter to allow 183, 202 (respectively) or other possible codes.
These actions are used throughout sanityTests.cxx
This defines a set of actions simialr to EXPECT_FUNCTOR_RESPONSE, but stores a target that is likely different from the sender. The implementation of the action's function is in TestSipEndPoint.cxx
Used to implement bye() and bye with target argument. See testInviteCallerHangsUp in sanityTests.cxx
Used to send a notification of an INVITE 200 receipt for transfer. See testAttendedExtensionToExtensionTransfer in sanityTests.cxx.
Not used. Present to allow malformed SIP messages. Useful for low level stack negative tests.
Looks just like SendX. Should be subsumed by send(x)?