re-INVITE for T.38 setup has two C= attribute lines

@sosherof wrote:

I'm currently testing a Cisco SPA122 ATA, connected to a fax machine, with a SIP peer. The ATA is registered as an extension in Asterisk and has T.38 enabled. Generally it works pretty well except that Asterisk (FreePBX 13.0.190.11 / Asterisk 13.7.1) always wants to be in the middle of the call (no shuffing/direct media), despite remove the 'Tt' from the dial options and enabling canrevite and directmedia. After adding directrtpsetup=yes to the chan_SIP advanced options, that improved somewhat as the initial SDP sent to the SIP peer has the ATA's IP address.

However, I noticed that for calls to the ATA, when Asterisk sends a re-INVITE to the SIP peer with the t.38 SDP, it includes the c= attribute twice. Without direct media, that's been okay because it's the same IP address (Asterisk's). However, with the directrtpsetup=yes flag, one C= attribute points to the ATA's IP and the other points to Asterisk. That's causes a communications problem.

Without direct media:

v=0
o=root 215368911 215368913 IN IP4 172.30.56.30
s=Asterisk PBX 13.7.1
c=IN IP4 172.30.56.30 <----- This is Asterisk's IP
t=0 0
m=image 4405 udptl t38
c=IN IP4 172.30.56.30
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:397
a=T38FaxUdpEC:t38UDPRedundancy

---

With direct media:

v=0
o=root 215368911 215368913 IN IP4 172.30.56.30
s=Asterisk PBX 13.7.1
c=IN IP4 172.30.56.30
t=0 0
m=image 4405 udptl t38
c=IN IP4 172.30.80.161 <---- This is the ATA's IP
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:397
a=T38FaxUdpEC:t38UDPRedundancy

Anybody else notice this? Is this a bug in chan_SIP?

Thanks,
Sam

Posts: 3

Participants: 2

Read full topic