[asterisk-bugs] [JIRA] (ASTERISK-28370) res_pjsip_t38: Not accepting Audio Re-invite after T.38 rejection

[Thomas Weber (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247688#comment-247688 ] 

Thomas Weber commented on ASTERISK-28370:
-----------------------------------------

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. 

> res_pjsip_t38: Not accepting Audio Re-invite after T.38 rejection
> -----------------------------------------------------------------
>
>                 Key: ASTERISK-28370
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28370
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_session, Resources/res_pjsip_t38
>    Affects Versions: 16.2.1
>         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.8
>            Reporter: Shane Short
>            Severity: Minor
>              Labels: fax, pjsip
>         Attachments: debug, pjsip.conf, sip_trace_11.txt
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)