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

[Joshua Colp]

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?

> 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.

Cheers,

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org