On Sat, Mar 28, 2015 at 6:48 PM, Joshua Colp <[email protected]> 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. > -- _____________________________________________________________________ -- 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
