If a remote endpoint reinvites to T.38 immediately the state machine
will go into a peer reinvite state. If a T.38 capable application
(such as ReceiveFax) queries it will receive this state. Normally
the application will then indicate so that the channel driver will
queue up the T.38 offer previously received. Once it receives this
offer the application will act normally and negotiate.
The res_pjsip_t38 module incorrectly partially squashed this indication.
This would cause the application to think the request had failed when
in reality it had actually worked.
This change makes it so that no T.38 control frames (or indications)
are squashed.
........
Merged revisions 429612 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429613
65c4cc65-6c06-0410-ace0-
fbb531ad65f3
data->session = session;
ao2_ref(session, +1);
- data->frame = frame;
+ data->frame = ast_frdup(frame);
+ if (!data->frame) {
+ ao2_ref(data, -1);
+ data = NULL;
+ }
return data;
}
if (ast_sip_push_task(session->serializer, t38_interpret_parameters, data)) {
ao2_ref(data, -1);
}
-
- f = &ast_null_frame;
} else if (f->frametype == AST_FRAME_MODEM) {
RAII_VAR(struct ast_sip_session_media *, session_media, NULL, ao2_cleanup);