----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4155/#review13717 -----------------------------------------------------------
branches/12/res/res_pjsip_nat.c <https://reviewboard.asterisk.org/r/4155/#comment24206> I don't think this is needed at all. branches/12/res/res_pjsip_nat.c <https://reviewboard.asterisk.org/r/4155/#comment24207> 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. branches/12/res/res_pjsip_nat.c <https://reviewboard.asterisk.org/r/4155/#comment24208> The PJSIP way to do this comparison would be: if (!pjsip_method_cmp(&rdata->msg_info.msg->line.req.method, &pjsip_invite_method)) { branches/12/res/res_pjsip_nat.c <https://reviewboard.asterisk.org/r/4155/#comment24209> Just a question - is this already on the dialog? (Do you need to clone it?) branches/12/res/res_pjsip_nat.c <https://reviewboard.asterisk.org/r/4155/#comment24210> If my approach is viable you'd want to drop the state listener here. - Joshua Colp 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
