[Home]

Summary:ASTERISK-28370: res_pjsip_t38: Not accepting Audio Re-invite after T.38 rejection
Reporter:Shane Short (shaneshort)Labels:fax pjsip
Date Opened:2019-04-02 07:28:38Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:Resources/res_pjsip_session Resources/res_pjsip_t38
Versions:16.2.1 Frequency of
Occurrence
Related
Issues:
Environment:Asterisk Version: Asterisk 16.2.1 Operationg System: Ubuntu 18.04.1 Kernel: 4.15.0-44-generic PJSIP Version: PJPROJECT version currently running against: 2.8Attachments:( 0) debug
( 1) pjsip.conf
( 2) sip_trace_11.txt
Description:When sending an audio based fax, asterisk rejects any re-invites (including back to audio after a T.38 rejection). Call flow is as follows:

- Normal call setup using G711A
- Upstream detects Fax Preamble and sends T.38 re-invite
- As I have T.38 gateway disabled (due to crashes which I shall report in future), we reject the re-invite with 488.
- The Upstream then re-invites us with G711A
- Asterisk rejects this re-invite with another 488.
- The upstream then sends a BYE.

I've tested this behavior using the same upstream and target number on Asterisk 11 w/chan-sip, and the call flow proceeds as you would expect.

I have attached debug logging and a successful Asterisk 11/chan-sip Negotiation with the same upstream peer.
Comments:By: Asterisk Team (asteriskteam) 2019-04-02 07:28:38.898-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Shane Short (shaneshort) 2019-04-02 07:31:40.797-0500

Debugging output and pjsip configuration exerpt
By: Shane Short (shaneshort) 2019-04-02 20:34:19.876-0500

SIP Trace from a working asterisk 11/chan_sip call on the same provider, to the same endpoint.
By: Shane Short (shaneshort) 2019-04-23 01:36:23.752-0500

HI All,
Has there been any progress on this issue? I can see it's being tracked internally at Digium. As I've had to completely disable T.38 on my upstream carrier, I'm not seeing a 50% fax failure rate, so ideally I'd to see if there's any workarounds I can use.
By: Joshua C. Colp (jcolp) 2019-04-23 04:34:21.357-0500

Any comments, suggestions, requests, or issue assignment will appear on this issue. There have been none.
By: Thomas Weber (tweber) 2019-08-05 02:04:38.264-0500

Hi, we're affected by the same issue. I invested some time to search for the cause. It is immediately reproducible whenever a incoming T.38 re-invite is processed.

It seems to be caused by a missing check res_pjsip_session.c:

{code}
struct ast_sip_session_media *ast_sip_session_media_state_add(struct ast_sip_session *session,
struct ast_sip_session_media_state *media_state, enum ast_media_type type, int position)
{
struct ast_sip_session_media *session_media = NULL;

/* It is possible for this media state to already contain a session for the stream. If this
* is the case we simply return it.
*/
if (position < AST_VECTOR_SIZE(&media_state->sessions)) {
return AST_VECTOR_GET(&media_state->sessions, position);
}
{code}

Problem is, that this if-statement does not take AST_STREAM_STATE_REMOVED into account. So it will reuse the failed T.38 image media_session when the audio re-invite fallback is received.
I assume the problem was already introduced when you added bundle support into asterisk 15 (ASTERISK-27076). Asterisk 13 is not affected at all.

I was able to workaround the problem by patching this if/else as a proof of concept. But the involved data structures are somewhat complex, so better having it fixed by somebody who knows more about it.

The attached debug log from OP @shaneshort contains also some evidence:

Incoming T.38 re-invite is declined as expected
{code}
…
[Mar 25 19:06:35] DEBUG[16554] res_pjsip_t38.c: Not deferring incoming SDP stream: T.38 not enabled on PJSIP/virtutel-syd-00000047
[Mar 25 19:06:35] DEBUG[16554] res_pjsip_session.c: Negotiating incoming SDP media stream 'image' using image SDP handler
[Mar 25 19:06:35] DEBUG[16554] res_pjsip_t38.c: Declining; T.38 not enabled on session
[Mar 25 19:06:35] DEBUG[16554] res_pjsip_session.c: Declining incoming SDP media stream 'image' at position '0
…
{code}

Subsequent Audo re-invite is declined as well because of reusing the image session_media from the failed T.38 re-invite (Negotiating incoming SDP media stream *'image'* using *audio SDP handler*). The audio sdp handler has, of course, no idea what to make out of a image format and so it is declined.

{code}
…
[Mar 25 19:06:35] DEBUG[16554] res_pjsip_session.c: Negotiating incoming SDP media stream 'image' using audio SDP handler
[Mar 25 19:06:35] DEBUG[16554] res_pjsip_sdp_rtp.c: Endpoint has no codecs for media type 'image', declining stream
[Mar 25 19:06:35] DEBUG[16554] res_pjsip_session.c: Declining incoming SDP media stream 'audio' at position '0
…
{code}

I can provide more logs/details if needed.
By: Niklas Larsson (pnlarsson) 2019-10-01 04:09:41.487-0500

@tweber - how did you patch the if?

I have the same issue upgrading from chan_sip to asterisk 16 and would like to try your workaround.
By: Thomas Weber (tweber) 2019-10-01 04:36:11.566-0500

@pnlarsson: recently asterisk 16.5.1 was released, it includes ASTERISK-28495 and i was wondering if it fixes this issue as well. Did you try 16.5.1?

You can try my fix/workaround for 16.5.0:

{code}
diff -Naur asterisk-16.5.0/res/res_pjsip_session.c asterisk-16.5.0_fix/res/res_pjsip_session.c
--- asterisk-16.5.0/res/res_pjsip_session.c 2019-07-25 09:38:14.000000000 +0000
+++ asterisk-16.5.0_fix/res/res_pjsip_session.c 2019-08-07 15:29:36.048479446 +0000
@@ -469,9 +469,16 @@
/* It is possible for this media state to already contain a session for the stream. If this
* is the case we simply return it.
*/
- if (position < AST_VECTOR_SIZE(&media_state->sessions)) {
- return AST_VECTOR_GET(&media_state->sessions, position);
- }
+        if (position < AST_VECTOR_SIZE(&media_state->sessions)) {
+                session_media = AST_VECTOR_GET(&media_state->sessions, position);
+                // WORKAROUND for https://issues.asterisk.org/jira/browse/ASTERISK-28370
+                if (session_media->type == AST_MEDIA_TYPE_IMAGE && type != AST_MEDIA_TYPE_IMAGE) {
+                        session_media = NULL;
+                } else {
+                        return session_media;
+                }
+        }
+

/* Determine if we can reuse the session media from the active media state if present */
if (position < AST_VECTOR_SIZE(&session->active_media_state->sessions)) {
{code}

It survived some internal testing but i am not an expert on asterisk internals.
Some feedback would be nice.
By: Niklas Larsson (pnlarsson) 2020-06-16 10:28:59.110-0500

Happy!

Tested with 16.11.0 and it's now working as intended - reinvite to alaw after 488 is working again!


By: Thomas Weber (tweber) 2020-06-17 00:51:10.290-0500

@pnlarsson: does 16.11.0 work for you because you patched it or is the problem indeed fixed? We're still running 16.9.0 (with this patch) but are about to upgrade soon.
By: Niklas Larsson (pnlarsson) 2020-06-17 01:13:00.120-0500

Without patch (and to make sure I downloaded the http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-16-current.tar.gz to make sure nothing was hidden in git).
By: Thomas Weber (tweber) 2020-06-17 02:17:00.801-0500

@pnlarsson: cool, thank you!

@jcolp / @shaneshort please maintain the issue