[asterisk-bugs] [JIRA] (ASTERISK-21373) Asterisk 11.2.1 T38 fax with NAT and SIP PROXY + RTPPROXY issues

Wed Apr 3 11:04:01 CDT 2013

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcello Lupo updated ASTERISK-21373:
-------------------------------------

    Attachment: log_fax_outgoing.zip

text log about the issue
                
> Asterisk 11.2.1 T38 fax with NAT and SIP PROXY + RTPPROXY issues
> ----------------------------------------------------------------
>
>                 Key: ASTERISK-21373
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21373
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/T.38
>    Affects Versions: 11.2.1
>         Environment: Linux with compiled from sources asterisk
>            Reporter: Marcello Lupo
>         Attachments: log_fax_outgoing.zip
>
>
> Good Afternoon,
> I'm contacting you because i worked a lot with opensips and rtpproxy developers trying solve issues with Asterisk behind NAT registered to sip proxy (opensips or Kamailio) using an rtpproxy to traverse NAT.
> We decided in the end that is not something that can be solved at rtpproxy/SIP proxy level.
> It is an unresolvable issue with outgoing fax calls from Asterisk to the outside world using T38.
> In short the problem is that when the fax call begins it start with voice codec and all is OK.
> When the remote fax answer the other party ask for a reinvite to switch in T38 protocol.
> Asterisk answer to this re INVITE with a 200 OK changing the RTP port for T38. The rtpproxy managing the call take as good the RTP port declared from Asterisk in the 200 OK and start to send rtp to this port  (that is still closed from outside). Rtpproxy will take valid this port till it will receive some packets from the real port that the Asterisk is using (out of the NAT).
> Since Asterisk do not send out any packet from the T38 port till it receive the RTP IN the fax call fail.
> I'm asking you if is possible to let asterisk send some packets (even fake ones or the real CNG fax tone) from the declared SDP port to the outside world. This will open the NAT hole that rtpproxy need to permit to all this situation to work correctly. This will avoid to have NAT mapping and so on in the customers router/firewall.
> Here a deep analisys of the issue:
> Sip Proxy Opensips 1.6.4 with Rtpproxy 1.2.1
> UAS (PSTNGW)  Audiocode Mediant 3000
> UAC (CPE) is Asterisk 11.2.1
> UAC behind symmetric NAT and place an outgoing fax call.
> UAC use INVITE with only voice codec and reINVITE in T38 changing the rtp port for t38.
> Call flow initial INVITE:
> INVITE from CPE —————> Proxy ———> PSTNGW
> 200 OK from PSTNGW —————> Proxy ——-> CPE
> Call flow of re INVITE
> re-INVITE from PSTNGW —————> Proxy ——-> CPE
> OK from CPE —————> Proxy ——-> PSTNGW
> INVITE from CPE and 200 OK from PSTNGW: the session start correctly with audio codec and packets are correctly relayed from rtpproxy.
> re INVITTE from PSTNGW and 200 OK from CPE: the call seems to be ok but the fax is not working. The reason is that on reINVITE 200 OK from CPE the CPE put a different port in the SDP and the rtpproxy update immediately the rtp stream that is currently going to the port of the voice codec and start immediately to send it to the port declared in the SDP from the CPE. The RTP do not go in to Asterisk because it still have not sent any packets from T38 port port (and it can be different port as well because it is behind NAT, not all routers/firewall make a symmetric nat from inside ports to outside ports).
> Rtpproxy in thi sphase is still in learning mode so it will send RTP to the declared SDP port till it receive at least one packet from the CPE. At this poing it will update the session and move the RTP (fax answering tone) to the correct port.
> In the text file attached (i need permission to attach files to post) you can find this info:
> Call flow is in this way:
> Proxy IP 46.21.181.200
> Rtpproxy IP 46.21.181.201
> CPE IP 89.97.245.244
> GW IP 46.21.181.244
> CPE start call on port 13462
> GW start call on port 6350
> after reinvite
> GW switch to port 6352
> CPE switch to port 4291 (closed in NAT so no way to work)
> You can fount the re INVITE at line 6180 and the 200 OK and ack form line 6300.
> I wait your comments.
> Thank you
> Best regards
> Marcello

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira