diff options
author | Matt Jordan <mjordan@digium.com> | 2015-11-20 21:08:49 -0600 |
---|---|---|
committer | Matt Jordan <mjordan@digium.com> | 2015-11-22 22:35:08 -0600 |
commit | 4875e5ac32f5ccad51add6a4216947bfb385245d (patch) | |
tree | 3a9ba5ca868afc20c76a8f5bfd10c31f41c2a818 /channels | |
parent | 2b94d9a10d5001ddb2c6a9aee4b66ee92ec3a3c8 (diff) |
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
Diffstat (limited to 'channels')
-rw-r--r-- | channels/chan_pjsip.c | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/channels/chan_pjsip.c b/channels/chan_pjsip.c index 1319094cf..0a8d1bcb5 100644 --- a/channels/chan_pjsip.c +++ b/channels/chan_pjsip.c @@ -162,11 +162,18 @@ static enum ast_rtp_glue_result chan_pjsip_get_rtp_peer(struct ast_channel *chan struct ast_sip_channel_pvt *channel = ast_channel_tech_pvt(chan); struct chan_pjsip_pvt *pvt; struct ast_sip_endpoint *endpoint; + struct ast_datastore *datastore; if (!channel || !channel->session || !(pvt = channel->pvt) || !pvt->media[SIP_MEDIA_AUDIO]->rtp) { return AST_RTP_GLUE_RESULT_FORBID; } + datastore = ast_sip_session_get_datastore(channel->session, "t38"); + if (datastore) { + ao2_ref(datastore, -1); + return AST_RTP_GLUE_RESULT_FORBID; + } + endpoint = channel->session->endpoint; *instance = pvt->media[SIP_MEDIA_AUDIO]->rtp; |