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

[Joshua Colp (JIRA)]

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

Joshua Colp commented on ASTERISK-27913:
----------------------------------------

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.

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



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