#4 pre-post scenarios

open
nobody
None
5
2012-12-15
2006-05-10
Olivier Jacques
No

Authors: Michael Hirschbichler
<michael.hirschbichler@boku.ac.at> and Joachim Fabini
<Joachim.Fabini@tuwien.ac.at>

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
used/accessed
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
register).

See Wiki:
http://sipp.sourceforge.net/wiki/index.php/Patches#Pre.2FPost_scenarios

Discussion

  • Hristo Trendev
    Hristo Trendev
    2006-07-10

    Logged In: YES
    user_id=1487592

    Can sombody provide this patch against more recent unstable
    version of sipp?