Add support for dynamic timers B & C for each of the client transactions

[IvanRibakov]

Rationale

I'm evaluating Repro for it's suitability to be used as a foundation for ESRP (Emergency Service Routing Proxy). In the world of emergency service providers, it is not uncommon for providers, as well as governmental agencies overseeing those providers to express requirements for the upper bound of the call connection time. Those requirements are typically much stricter than the Timer B/Timer C values specified in the RFC 3261 and often vary based on the destination agency and a number of other call parameters.

As such, I'm looking for ability to specify custom TimerB and TimerC values for each of the Repro targets (serially forked). This PR proposes a solution to the problem.

[sgodin]

Bracket on separate line. :)

Also trying to wrap my head around why we are copying the unique_ptr. Using a unique_ptr gives the user the impression you are handing of the data to be managed by the class, so why copy here? If the copy is necessary, we should think about changing the constructor signature to perhaps just take in a raw pointer.

[IvanRibakov]

Apologies for going quite for some time, other work stuff came up.

Using a unique_ptr gives the user the impression you are handing of the data to be managed by the class

Not unless unique_ptr is passed by const reference (assuming no foul play by receiver of the const ref, like casting const away).

If the copy is necessary, we should think about changing the constructor signature to perhaps just take in a raw pointer.

I wanted to avoid using raw pointer to prevent it from being accidentally stored(copied) and outliving the unique_ptr that manages it.

When deciding on how best to pass SipMessageOptions to the constructor I used this SO answer for inspiration and reference. Let me know if reasoning above makes sense to you or if you'd like to switch to raw pointer approach in the end.

[sgodin]

Let's talk first about the need to copy the SipMessageOptions class in the constructor. Perhaps the need to copy should be up to the caller to decide what they want to do. ie: Take in a std::unique_ptr by value and std::move it in the constructor. If a copy is needed, then the caller can copy the unique_ptr before passing it in. Thoughts?

Which all leads me to the next question.... The changes in this pull request support something you are enhancing repro with. Do you intend to submit a new processor or some new functionality to repro to make use of these changes publicly?

[IvanRibakov]

If a copy is needed, then the caller can copy the unique_ptr before passing it in. Thoughts?

Done

---

Do you intend to submit a new processor or some new functionality to repro to make use of these changes publicly?

I do not have such plans at the moment.