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

George Joseph george.joseph at fairview5.com
Sat Mar 28 19:21:18 CDT 2015


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.

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.

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.

The result of all of this is that we'll be able to generate events for
contact status (ASTERISK-24863) which in turn will help is provide
functionality like marking an endpoint unavailable when all of its
contacts are unavailable.

thoughts?



More information about the asterisk-dev mailing list