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

[George Joseph]

On Sat, Mar 28, 2015 at 6:48 PM, Joshua Colp <jcolp at digium.com> wrote:
> George Joseph wrote:
>>
>> I've been trying to figure out how to get more control of the
>> pjsip_options qualify process.  Specifically, how to get a timely
>> positive indication of failure and how to generate events on a status
>> change.
>>
>> Right now when a contact is qualified, it's immediately marked as
>> UNAVAILABLE.  If a response to the OPTIONS message comes back, it's
>> marked as AVAILABLE again and the round trip time calculated.   The
>> status flapping even in normal operation makes generating events
>> tricky because the subscriber will see up/down events even if the
>> contact is really AVAILABLE.   Now the pjsip transaction will
>> eventually time out at an unconfigurable 32 seconds and call the
>> callback but 32 seconds is a long time.  This is also an issue if the
>> qualify_frequency is less than 32 seconds since they'll be multiple
>> pjsip transactions in progress for the same contact.
>
>
> 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.

>
>> I'm also a little concerned that the albeit short UNAVAILABLE status
>> between the request and response might be causing calls to not go
>> through even though the contact is really available.
>>
>> I've refactored pjsip_options with it's own configurable timeout timer
>> and eliminated the need for the flap and it works well BUT, there's no
>> way to cancel an inflight pjsip transaction because you need the
>> pjsip_transaction structure to call pjsip_tsx_terminate.  So we're
>> back to transactions hanging out that aren't valid if the
>> qualify_timeout is less than pjsip's 32 seconds.
>>
>> I've been investigating how to get access to the pjsip_transaction and
>> it's fairly easy but requires a refactor of
>> res_pjsip/endpt_send_request.    Right now
>> res_pjsip/endpt_send_request calls libpjsip/pjsip_endpt_send_request
>> but that's just a wrapper around a few other public pjsip calls and
>> that wrapper generates the pjsip_transaction structure.
>
>
> It should be possible to bump the ref for the tdata up before sending it.
> After sending it then use pjsip_tsx_create_key with the information from the
> data to generate the key and pjsip_tsx_layer_find_tsx to get the
> transaction. It's not direct, but should provide it and leverages the
> existing API.
>
>> So, I'm proposing pulling libpjsip/pjsip_endpt_send_request up into
>> res_pjsip.   It's 2 short function and a pjsip_module structure with
>> no access to any private pjsip stuff.   Now we'll have the ability to
>> terminate the transaction AND it seems that there's a timeout member
>> of pjsip_transaction which I'm hoping (but haven't tested) will
>> eliminate the need to add timeout processing in pjsip_options.
>
>
> I would like to avoid such things as much as possible. Pulling PJSIP code
> into Asterisk like this should be avoided at all costs since if the
> underlying way it's done is changed we have to change with it (including
> being backwards compatible with earlier versions). It also means that if
> there's a bug in that area (albeit unlikely) we won't get the fix unless we
> explicitly keep watch.
>