summaryrefslogtreecommitdiff
path: root/channels/chan_pjsip.c
diff options
context:
space:
mode:
authorMatt Jordan <mjordan@digium.com>2015-11-20 21:08:49 -0600
committerMatt Jordan <mjordan@digium.com>2015-11-22 22:37:29 -0600
commit726ee873a6d88a133cf6d75fc97fb1af6af09c52 (patch)
tree76452602903a9000c586898f1b88b29f3d6ef7a2 /channels/chan_pjsip.c
parent04874067818584b5824acc24ed2835bb158f3ce2 (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/chan_pjsip.c')
-rw-r--r--channels/chan_pjsip.c7
1 files changed, 7 insertions, 0 deletions
diff --git a/channels/chan_pjsip.c b/channels/chan_pjsip.c
index c98be3565..32291e54c 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;