[Asterisk-code-review] chan pjsip: Handle T.38 faxes with direct media bridges (asterisk[13])

[Matt Jordan]

Hello Anonymous Coward #1000019,

I'd like you to reexamine a change.  Please visit

    https://gerrit.asterisk.org/1668

to look at the new patch set (#2).

Change subject: chan_pjsip: Handle T.38 faxes with direct media bridges
......................................................................

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: I7c3575d02b2b6b82ebb6c969cb01545b57a95304

Fixup

Change-Id: Iabd6aa578e633d16e6b9f342091264e4324a79eb
---
M channels/chan_pjsip.c
M res/res_pjsip_t38.c
2 files changed, 49 insertions(+), 1 deletion(-)


  git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/68/1668/2
-- 
To view, visit https://gerrit.asterisk.org/1668
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Iabd6aa578e633d16e6b9f342091264e4324a79eb
Gerrit-PatchSet: 2
Gerrit-Project: asterisk
Gerrit-Branch: 13
Gerrit-Owner: Matt Jordan <mjordan at digium.com>
Gerrit-Reviewer: Anonymous Coward #1000019