No subject

ing would certainly be an improvement..

This looks like a [feature request/improvement|https://wiki.asterisk.org/wi=
ki/display/AST/Asterisk+Issue+Guidelines#AsteriskIssueGuidelines-Howtoreque=
stafeature]. Can you provide a patch for the behavior?

If you feel this is a bug, can you point to an RFC or other spec that would=
 suggest Asterisk's current behavior should be different?
               =20
> Asterisk 11.2.1 T38 fax with NAT and SIP PROXY + RTPPROXY issues
> ----------------------------------------------------------------
>
>                 Key: ASTERISK-21373
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-213=
73
>             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
>            Assignee: Marcello Lupo
>         Attachments: log_fax_outgoing.zip
>
>
> Good Afternoon,
> I'm contacting you because i worked a lot with opensips and rtpproxy deve=
lopers 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 rtpprox=
y/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 i=
n 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 fro=
m 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 rece=
ive 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 recei=
ve the RTP IN the fax call fail.
> I'm asking you if is possible to let asterisk send some packets (even fak=
e 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 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94> Proxy =E2=
=80=94=E2=80=94=E2=80=94> PSTNGW
> 200 OK from PSTNGW =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94> Proxy =
=E2=80=94=E2=80=94-> CPE
> Call flow of re INVITE
> re-INVITE from PSTNGW =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94> Prox=
y =E2=80=94=E2=80=94-> CPE
> OK from CPE =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94> Proxy =E2=80=
=94=E2=80=94-> 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 t=
he fax is not working. The reason is that on reINVITE 200 OK from CPE the C=
PE 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 R=
TP 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 N=
AT, not all routers/firewall make a symmetric nat from inside ports to outs=
ide ports).
> Rtpproxy in thi sphase is still in learning mode so it will send RTP to t=
he declared SDP port till it receive at least one packet from the CPE. At t=
his poing it will update the session and move the RTP (fax answering tone) =
to the correct port.
> In the zip file attached you can find a text file with 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 administrato=
rs: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.j=
spa
For more information on JIRA, see: http://www.atlassian.com/software/jira