[asterisk-dev] RFC: Refactor qualify and res_pjsip/endpt_send_request

[Mark Michelson]

On 03/31/2015 01:51 AM, Olle E. Johansson wrote:
> On 30 Mar 2015, at 16:54, Mark Michelson <mmichelson at digium.com> wrote:
>
>> On 03/28/2015 08:06 PM, Joshua Colp wrote:
>>> George Joseph wrote:
>>>>> The fact that it goes to unavailable would be a bug. Why does it do so?
>>>> Mark should probably chime in here but I think it's because the
>>>> earliest you could get a response from pjsip when a contact isn't
>>>> reachable is the unconfigurable 32 seconds.   As I said that's a long
>>>> time to leave a contact available when it really isn't. Without
>>>> implementing our own timer setting the contact to unavailable was
>>>> probably the lesser of 2 evils.
>>> No matter what there's going to be a period where you are potentially wrong. I don't think making it unavailable was done on purpose.
>>>
>> Actually, I believe the timer may be configurable. In the type=system settings, there are timer_t1 and timer_b settings. timer_t1 is the base used for determining the retransmission interval, and timer_b is the maximum time we will wait before giving up sending the request. The defaults for these values are 500 ms and 32000 ms respectively. If you were to change timer_b to be a smaller value, then presumably you would have a shorter time before the transaction times out.
>>
>> A couple of caveats about these settings
>> 1) Since they're in the "type=system" settings, any change you make requires an Asterisk restart in order to take effect.
> Are you serious? That's a very strange design. Without knowing anything about PJSIP, I think that is something that
> needs to be fixed. There are several SIP phones based on PJSIP where I can set timers without restarting. Wonder
> how they did it.
The issue is that the configured timer values are copied by the PJSIP 
transaction layer when the transaction layer is initialized. Any changes 
made to the configured timer values are not taken into account by the 
transaction layer since it never re-reads the configured values.

If you were able to change timers, then either
1) The implementors were using a much lower level of the PJSIP API in 
order to manage timers themselves.
2) They had made changes to the PJSIP source code to allow the 
transaction layer to re-learn configured timer values.
3) They were stopping and restarting PJSIP under the hood each time that 
the timer values were changed.

As far as requiring an Asterisk restart goes, I suppose that's not 
actually true anymore. I had forgotten that we had made res_pjsip.so 
unloadable now. You could actually unload res_pjsip.so and then load it 
again to apply type=system changes on a running Asterisk system. It's 
still not pleasant, but it's better than a full-scale restart.

>
>> 2) PJSIP applies these timers globally. They will affect ALL SIP transactions, not just the OPTIONS transactions from the qualify checks.
> That seems very strange, but I have to trust you here. It makes the channel driver rather unusable in gateway situations where
> it's a requirement that I have one set of timers for my internal systems and one for external clients.
>
> /O