[asterisk-bugs] [JIRA] (ASTERISK-19013) T.38 port negotiation problem
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Fri Mar 13 19:22:34 CDT 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-19013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Jordan updated ASTERISK-19013:
-----------------------------------
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 at 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 at SipProvider.com>;tag=as74eb67a4
To: <sip:973XXXXXX at SipProvider.com>;tag=gj-2k5-4e8cde92-000064f6-0007b7cfR5fde497f.b
Contact: <sip:xxxxxxxxxx at 10.XX.XXX.XX:5060>
Call-ID: 08d7b6e108d0a94811e9c134381289f3 at 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 at SipProvider.com>;tag=as74eb67a4
To: <sip:973XXXXXX at SipProvider.com>;tag=gj-2k5-4e8cde92-000064f6-0007b7cfR5fde497f.b
Call-ID: 08d7b6e108d0a94811e9c134381289f3 at 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 at 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}
was:
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
[Dec 13 12:14:53] VERBOSE[31503] chan_sip.c: Reliably Transmitting (NAT) to 193.XX.XXX.XX:5060:
INVITE sip:973XXXXXX at 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 at SipProvider.com>;tag=as74eb67a4
To: <sip:973XXXXXX at SipProvider.com>;tag=gj-2k5-4e8cde92-000064f6-0007b7cfR5fde497f.b
Contact: <sip:xxxxxxxxxx at 10.XX.XXX.XX:5060>
Call-ID: 08d7b6e108d0a94811e9c134381289f3 at 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 at SipProvider.com>;tag=as74eb67a4
To: <sip:973XXXXXX at SipProvider.com>;tag=gj-2k5-4e8cde92-000064f6-0007b7cfR5fde497f.b
Call-ID: 08d7b6e108d0a94811e9c134381289f3 at 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 at 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
> T.38 port negotiation problem
> -----------------------------
>
> Key: ASTERISK-19013
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-19013
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/T.38
> Affects Versions: 1.8.8.0
> Reporter: Marc Huguet
> Severity: Minor
>
> 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 at 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 at SipProvider.com>;tag=as74eb67a4
> To: <sip:973XXXXXX at SipProvider.com>;tag=gj-2k5-4e8cde92-000064f6-0007b7cfR5fde497f.b
> Contact: <sip:xxxxxxxxxx at 10.XX.XXX.XX:5060>
> Call-ID: 08d7b6e108d0a94811e9c134381289f3 at 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 at SipProvider.com>;tag=as74eb67a4
> To: <sip:973XXXXXX at SipProvider.com>;tag=gj-2k5-4e8cde92-000064f6-0007b7cfR5fde497f.b
> Call-ID: 08d7b6e108d0a94811e9c134381289f3 at 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 at 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}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list