[Home]

Summary:ASTERISK-27913: chan_sip / chan_pjsip: T.38 fails if SDP negotiation results in declined stream
Reporter:George Diamantopoulos (gd)Labels:fax pjsip
Date Opened:2018-06-12 12:33:29Date Closed:
Priority:MinorRegression?No
Status:Open/NewComponents:Channels/chan_pjsip Channels/chan_sip/T.38 Resources/res_pjsip_sdp_rtp Resources/res_pjsip_t38
Versions:11.25.3 13.21.0 Frequency of
Occurrence
Related
Issues:
Environment:For Asterisk 13: Debian Stretch Asterisk built from source: 13.21.0 For Asterisk 11: Debian Jessie Asterisk built from source: 11.25.3Attachments:
Description:I have come across the following issue with what I believe to be Cisco SIP Endpoints initiating a fax call to an Asterisk running the ReceiveFax application in the dialplan or acting as a T.38 gateway for another endpoint.

The issue manifests as follows:
# Incoming INVITE from remote (Cisco) endpoint
# Asterisk answers with 200 OK
# Asterisk sends re-INVITE with a single offer for UDPTL in SDP
# Cisco endpoint replies with 200 OK, and the SDP has the following contents:
{noformat}
   v=0
   o=- 29768103 29768104 IN IP4 0.0.0.0
   s=SBC call
   c=IN IP4 0.0.0.0
   t=0 0
   m=image 0 udptl t38
   a=sendrecv
{noformat}
# Fax transmission fails, instead of Asterisk issuing a re-INVITE with an audio offer in either alaw or ulaw
Comments:By: Asterisk Team (asteriskteam) 2018-06-12 12:33:31.378-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].

By: Joshua C. Colp (jcolp) 2018-06-12 12:36:29.226-0500

The Cisco is not responding correctly. It should have sent a 488 rejecting the re-invite, and things would have carried on. It accepted the reinvite, but declined the specific stream leaving no other streams. I don't think there's any ability in 13 for it to know that this specific scenario happened and that it needs to reinvite back to work around the brokenness of the Cisco.

By: George Diamantopoulos (gd) 2018-06-12 12:41:06.041-0500

This issue seems to affect both chan_sip and chan_pjsip.

For asterisk 11 I tried the following patch with which I was able to successfully receive at least one fax originating from one of the Cisco endpoints exhibiting the problem:
{noformat}
--- a/channels/chan_sip.c
+++ b/channels/chan_sip.c
@@ -23201,6 +23201,20 @@
               p->invitestate = INV_TERMINATED;
               ast_set_flag(&p->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED);
               xmitres = transmit_request(p, SIP_ACK, seqno, XMIT_UNRELIABLE, TRUE);
+               if (AST_LIST_EMPTY(&p->offered_media) && p->udptl && p->t38.state == T38_LOCAL_REINVITE) {
+                       ast_log(LOG_WARNING, "Got 200 OK with no valid media streams\n");
+                        change_t38_state(p, T38_REJECTED);
+                        transmit_reinvite_with_sdp(p, FALSE, FALSE);
+                }
               check_pendings(p);
               break;
{noformat}

I'm only including this here in case it might provide a hint to anyone with some insight in asterisk's internals, as I have no idea if this breaks anything somewhere else. I have tried a similar patch with Asterisk 13, but I wasn't successful in repeating the fax reception.

I gave up trying to do something similar with pjsip, due to lack of time and skills...

By: George Diamantopoulos (gd) 2018-06-12 14:10:11.487-0500

@Joshua Colp
I believe you're referring to the two following excerpts of RFC3264?
{noformat}
  The agent receiving the offer MAY generate an answer, or it MAY
  reject the offer.  The means for rejecting an offer are dependent on
  the higher layer protocol.  The offer/answer exchange is atomic; if
  the answer is rejected, the session reverts to the state prior to the
  offer (which may be absence of a session).
{noformat}
Which I interpret as: an answer is one where at least one stream is accepted and a rejection is one where all streams offered are rejected. In the latter case, it is through the higher level protocol (in this case, SIP) that this information is to be conveyed, not SDP

This latter interpretation of the term "rejection" is supported by this additional excerpt (noting the difference between "to reject a session" and "to reject a media stream or media offer"):
{noformat}
  If there are no media formats in common for all streams, the entire
  offered session is rejected.
{noformat}

So I believe you are correct in that the Cisco is misbehaving here. However, at least in asterisk 11 and chan_sip, I was able to selectively handle those 200 OKs with the following conditional checks in the aforementioned patch:

# AST_LIST_EMPTY(&p->offered_media)
I understand this will return true if the SIP message processed contains zero offered media streams
# p->udptl
I don't know why I checked for this, it made sense at the time I guess. Since negotiation hasn't succeeded, it now seems weird for this to be non-false
# p->t38.state == T38_LOCAL_REINVITE
This is critical in that we only want to act if we're processing a response to a request we sent out in order to make the switch to T38 over UDPTL

Are you saying there is no way to check for this case in the asterisk 13/PJSIP codepath?

By: Joshua C. Colp (jcolp) 2018-06-12 14:13:51.030-0500

It's not a scenario handled or one I've given any thought, so I really have no idea of what is truly required and the ripples that could occur.