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

General Help
1

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

2

This would be better posted in asterisk forums.

3

Actually, looks like it might have been fixed in Asterisk 13.8 (see change ID Ibf6c485f843a1be6dee58a47b33d81a7a8cbe3b0). I’ll upgrade to the latest FreePBX distro, which includes an upgrade to Asterisk 13.12.

-Sam

4

This SDP is valid, although first c line is not making much sense in this case. In SDP there may be “global”/default c line (172.30.56.30) and also separate c lines for each or some of the media that are taking higher priority. It’s making sense e.g. for video calls when video media can be passed directly to phone while audio routed through PABX.
In this case as there is only single media first c line should be ignored by device as it’s overridden by media-specific line.

5

I hear what you’re saying but the m= line then should be below the second c= line, since the media being described by the m= line owns all of the a= attribute lines that follow.

6

Ownership does not imply order between attributes and connection line as second “c” line is also “owned” by media. Moving m line down would make second connection line “session level” connection line and there is only one allowed:

5.7.  Connection Data ("c=")

      c=<nettype> <addrtype> <connection-address>

   The "c=" field contains connection data.

   A session description MUST contain either at least one "c=" field in
   each media description or a single "c=" field at the session level.
   It MAY contain a single session-level "c=" field and additional "c="
   field(s) per media description, in which case the per-media values
   override the session-level settings for the respective media.