Authors: Michael Hirschbichler
<firstname.lastname@example.org> and Joachim Fabini
Please find attached a commented example scenario file
(UAS) that should be used as a discussion base for the
planned SIPp extension.
For mailing list members who did not follow our initial
discussion: The Pre- and Post-Scenarios are required to
Register and De-Register a SIPp UAS without being forced
to start SIPp twice with distinct scenario files.
Some words on "behind-the-scene" details and decisions
not mentioned within the example:
Initially we planned to have three separate files:
One for pre- main- and post-scenario. We decided to use
one single file instead because headers from the
registration 200 OK must be accessible from within the main
scenario. It seems more intuitive to us to have a
<prescenario>, a <scenario> and a <postscenario> section
within one single scenario file.
It would be even more flexible to couple one <prescenario>
and one <postscenario> with several <scenario> sections but
this requires (most likely) a complete re-coding of SIPp.
Why do we think about this solution: E.g. to support
presence and voice calls within the same scenario. Presence
events can interleave with the voice call signaling but
require the same registration data as signaling.
On our requirements:
1. Header values returned within the registration 200 OK
must be available throughout the main scenario. E.g.,
the <Service-Route:> header value in the Register 200OK
contains the route that must be inserted into the
<Route> header field of subsequent Invite messages -
in the main scenario.
So we plan to provision all Register-200 OK header values
in [last_pre_****] header fields that can be
within the main scenario.
2. Automatic Re-Registration (Re-execution of pre-scenario)
must be supported. The headers contained in the reply
to the last Re-Register received by SIPp overwrite the
previous ones stored in the [last_pre_***] headers.
We did not find any case where this overwriting does
_NOT_ work, i.e., where the header values of the
initial REGISTER should be preserved.
A special keyword is needed to re-send the Re-Register
at the required point in time (the Registrar might change
the re-register time value passed in the initial