[Home]

Summary:ASTERISK-19013: T.38 port negotiation problem
Reporter:Marc Huguet (mhuguet)Labels:
Date Opened:2011-12-13 07:04:13.000-0600Date Closed:2015-03-13 19:12:18
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:1.8.8.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:
Description:We use the following scenario: spa2102 <-> Asterisk-gw <-> SipProvider.

a) We can fax with T.38 from spa2102 to asterisk-gw without problems (with res_fax_spandsp - RecvFax)
b) We can fax with T.38 from asterisk-gw to SipProvider without problems (with res_fax_spandsp - SendFax).
c) But when we try to send a fax from spa2102 through Asterisk-gw to SipProvider the fax is never sent.

The problem is that in the T38 reinvite from asterisk to SipProvider we offer a new udptl port different from the current rtp port, and the SipProvider OKs to the current rtp port.

After that transmission works only if the first udptl packet is sent from asterisk-gw to SipProvider. If this occurs SipProviders uses new udptl port and communication works like a charm (this occurs in b). If not, SipProvider uses old rtp port and asterisk the new one and communication fails (this occurs in c).

Works for asterisk-1.10-rc2
{noformat}
[Dec 13 12:14:53] VERBOSE[31503] chan_sip.c: Reliably Transmitting (NAT) to 193.XX.XXX.XX:5060:
INVITE sip:973XXXXXX@212.XX.XXX.XX:5060;user=phone;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.XX.XXX.XX:5060;branch=z9hG4bK72841753;rport
Route: <sip:193.XX.XXX.XX;lr=on;ftag=as74eb67a4>,<sip:194.XX.XXX.XX;lr=on>
Max-Forwards: 70
From: "USER" <sip:xxxxxxxxxx@SipProvider.com>;tag=as74eb67a4
To: <sip:973XXXXXX@SipProvider.com>;tag=gj-2k5-4e8cde92-000064f6-0007b7cfR5fde497f.b
Contact: <sip:xxxxxxxxxx@10.XX.XXX.XX:5060>
Call-ID: 08d7b6e108d0a94811e9c134381289f3@SipProvider.com
CSeq: 104 INVITE
User-Agent: FPBX-2.9.0(1.8.7.2)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
X-asterisk-Info: SIP re-invite (External RTP bridge)
Content-Type: application/sdp
Content-Length: 267
v=0
o=root 1597491899 1597491901 IN IP4 10.XX.XXX.XX
s=Asterisk PBX 1.8.7.2
c=IN IP4 10.XX.XXX.XX
t=0 0
m=image 4814 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:397
a=T38FaxUdpEC:t38UDPRedundancy
<--- SIP read from UDP:193.XX.XXX.XX:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.XX.XXX.XX:5060;received=191.XXX.XX.XX;branch=z9hG4bK72841753;rport=5060
From: "USER" <sip:xxxxxxxxxx@SipProvider.com>;tag=as74eb67a4
To: <sip:973XXXXXX@SipProvider.com>;tag=gj-2k5-4e8cde92-000064f6-0007b7cfR5fde497f.b
Call-ID: 08d7b6e108d0a94811e9c134381289f3@SipProvider.com
CSeq: 104 INVITE
Record-Route: <sip:194.XX.XXX.XX;lr=on>
Record-Route: <sip:193.XX.XXX.XX;lr=on;ftag=as74eb67a4>
Contact: <sip:973XXXXXX@212.XX.XXX.XX:5060;user=phone;transport=udp>
Content-Length: 281
Content-Type: application/sdp
Comedia: no
v=0
o=HuaweiSoftX3000 88134567 88134569 IN IP4 19.196.0.0
s=Sip Call
c=IN IP4 19.196.0.0
t=0 0
m=image 25632 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:397
a=T38FaxUdpEC:t38UDPRedundancy
a=nortpproxy:yes
{noformat}
Comments:By: Joshua C. Colp (jcolp) 2015-03-13 19:12:18.760-0500

This is not a bug. Asterisk will stop sending RTP as soon as it stops coming in, but that does not guarantee that there are no RTP packets in-flight already or out of its control. It would be impossible to make sure of that.