[asterisk-bugs] [JIRA] (ASTERISK-19013) T.38 port negotiation problem

[Joshua Colp (JIRA)]

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

Joshua Colp closed ASTERISK-19013.
----------------------------------

    Resolution: Not A Bug

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.

> 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
> [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



--
This message was sent by Atlassian JIRA
(v6.2#6252)