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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
