[asterisk-bugs] [JIRA] (ASTERISK-27913) chan_sip / chan_pjsip: T.38 fails if SDP negotiation results in declined stream

[George Diamantopoulos (JIRA)]

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

George Diamantopoulos edited comment on ASTERISK-27913 at 6/12/18 2:10 PM:
---------------------------------------------------------------------------

@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?


was (Author: gd):
@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 messing things up. 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?

> chan_sip / chan_pjsip: T.38 fails if SDP negotiation results in declined stream
> -------------------------------------------------------------------------------
>
>                 Key: ASTERISK-27913
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27913
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip, Channels/chan_sip/T.38, Resources/res_pjsip_sdp_rtp, Resources/res_pjsip_t38
>    Affects Versions: 11.25.3, 13.21.0
>         Environment: For Asterisk 13:
>   Debian Stretch
>   Asterisk built from source: 13.21.0
> For Asterisk 11:
>   Debian Jessie
>   Asterisk built from source: 11.25.3
>            Reporter: George Diamantopoulos
>            Severity: Minor
>              Labels: fax, pjsip
>
> 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 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



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