> On Nov. 10, 2014, 2:24 p.m., Joshua Colp wrote: > > branches/12/res/res_pjsip_nat.c, lines 62-77 > > <https://reviewboard.asterisk.org/r/4155/diff/1/?file=68767#file68767line62> > > > > Instead of maintaining this in a list why not alloc the mapping from > > the dialog pool, pass it in as a parameter to the state listener, and store > > it on the dialog? That way you don't need to do a list lookup for this sort > > of, you have direct access to it.
Of course, you'd need to add a state listener for each dialog over a transport but meh. - Joshua ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4155/#review13717 ----------------------------------------------------------- On Nov. 6, 2014, 3:49 p.m., opticron wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4155/ > ----------------------------------------------------------- > > (Updated Nov. 6, 2014, 3:49 p.m.) > > > Review request for Asterisk Developers and Joshua Colp. > > > Bugs: ASTERISK-24486 > https://issues.asterisk.org/jira/browse/ASTERISK-24486 > > > Repository: Asterisk > > > Description > ------- > > This modifies contact rewriting to revert to the original contact URI for a > dialog when persistent transports shut down. > > Some calls can enter a condition where their contact URI from the initial > incoming invite was rewritten for a reliable transport, but that transport > has been shut down due to inactivity. Such reliable transports can not be > re-established since the remote host was never listening on the associated > port. In cases such as these, it is useful to be able to fall back to the > original contact URI since it might be accessible and allow the call to > continue normally. > > > Diffs > ----- > > branches/12/res/res_pjsip_nat.c 425222 > > Diff: https://reviewboard.asterisk.org/r/4155/diff/ > > > Testing > ------- > > Verified that this allowed the call to operate normally despite the original > reliable connection being torn down where this situation was experienced. > > > Thanks, > > opticron > >
-- _____________________________________________________________________ -- 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
