chan_pjsip: Handle T.38 faxes with direct media bridges
authorMatt Jordan <mjordan@digium.com>
Sat, 21 Nov 2015 03:08:49 +0000 (21:08 -0600)
committerMatt Jordan <mjordan@digium.com>
Mon, 23 Nov 2015 04:35:08 +0000 (22:35 -0600)
commit4875e5ac32f5ccad51add6a4216947bfb385245d
tree3a9ba5ca868afc20c76a8f5bfd10c31f41c2a818
parent2b94d9a10d5001ddb2c6a9aee4b66ee92ec3a3c8
chan_pjsip: Handle T.38 faxes with direct media bridges

When a channel is in a direct media bridge, a re-INVITE may arrive that forces
Asterisk to re-negotiate the media to a T.38 fax. When this occurs, the bridge
must change its technology to a simple bridge, and re-INVITE the media back
to Asterisk.

Generally, this logic mostly already exists in Asterisk. However, prior to this
patch, there were a few bugs:
(1) The T.38 framehook currently prevents a channel capable of T.38 faxes from
    ever entering into a direct media bridge. This applies even when the only
    media being passed over the channel is audio. This patch fixes this bug
    by having the framehook specify that it defers caring about any frame type.
    This allows the channels to enter into a direct media bridge, which will
    be broken when a re-INVITE is received.
(2) When a re-INVITE is received, nothing instructed the bridging layer to
    re-inspect the allowed bridging technology. This now occurs when either
    a re-INVITE is received from a peer, or when a response is received from
    the far end (that is, when the T.38 state changes to either
    T38_PEER_REINVITE or T38_LOCAL_REINVITE).
(3) chan_pjsip needs to do a small amount of work to prevent a direct media
    bridge from being chosen when a T.38 session is in progress. When a T.38
    session supplement has a t38 datastore - which is added when we detect
    we should start thinking about T.38 on a channel - we now refuse a native
    RTP bridge.
(4) When a BYE request is received, we don't terminate the T.38 session. If
    the other side of a T.38 fax survives the hangup (due to the 'g' flag
    in Dial, for example), we don't currently re-INVITE the media on the
    other channel back to audio. This patch now has res_pjsip_t38 intercept
    BYE requests and inform the far side that the T.38 session is terminated.
    This naturally causes the correct re-INVITEs to be sent.

ASTERISK-25582

Change-Id: Iabd6aa578e633d16e6b9f342091264e4324a79eb
channels/chan_pjsip.c
res/res_pjsip_t38.c