Summary: | ASTERISK-19013: T.38 port negotiation problem | ||
Reporter: | Marc Huguet (mhuguet) | Labels: | |
Date Opened: | 2011-12-13 07:04:13.000-0600 | Date Closed: | 2015-03-13 19:12:18 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | 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. |