[asterisk-bugs] [JIRA] (ASTERISK-26100) [patch] Asterisk will reject, with a 488, subsequent T.38 reinvite to T.38 negotiation.

[Asterisk Team (JIRA)]

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

Asterisk Team commented on ASTERISK-26100:
------------------------------------------

The severity of this issue has been automatically downgraded from "Blocker" to "Major". The "Blocker" severity is reserved for issues which have been determined to block the next release of Asterisk. This severity can only be set by privileged users. If this issue is deemed to block the next release it will be updated accordingly during the triage process.

> [patch] Asterisk will reject, with a 488, subsequent T.38 reinvite to T.38 negotiation.
> ---------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26100
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26100
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/T.38
>    Affects Versions: 11.22.0
>         Environment: Ubuntu 14.04 LTS (asterisk is always compiled from scratch)
>            Reporter: Parantido Julius De Rica
>
> Hi all,
> I already searched bug tracker and found similar solved bug, but no one fixed my issue.
> I've te following scenario:
> FAX (Offerer) <--> SIP Server <--> Asterisk T.38 Passthrough <--> Oracle SBC (ex Acme Packet) <--> PSTN <--> Fax (Receiver)
> Offerer starts a Fax transmission as in-audio call (g729 coded). This call get switched by network side (Oracle SBC) as T.38 with a first invite. During fax negotiation Oracle SBC send back a second T.38 re-invite and Asterisk answer with a 488 after 5 seconds due the following code statement:
> p->t38id = ast_sched_add(sched, 5000, sip_t38_abort, dialog_ref(p, "passing dialog ptr into sched structure based on t38id for sip_t38_abort."));
> Reading code seems that a reinvite is not allowed, during fax transmission, after channel is placed in AST_STATE_UP.
> Reading all RFCs and ITU-T specifications no one describe this scenario but  at the same times no one disallow it.
> I wrote a patch for chan_sip.c to handle this behaviour. All seems to works fine for all cutomers that reports to me this issue and no regressions are observed.
> I attached a PCAP trace (for better scenario description) and a patch.
> Regards



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