canreinvite=yes, allow=g729,ulaw in Asterisk, for both ATA and SIP GWY in Asterisk’s sip.conf and there is no NAT involved. SIP GWY has g729 and g711ulaw codecs enabled.
Voice call is working fine using g729. The RTP for voice call between ATA and PSTN go directly between ATA and SIP GWY. Asterisk is there doing SIP signalling.
g729 is configured as prefered codec in the ATA and the ATA has the capability of switching to g711ualw when fax CNG or CED is detected. Idea is to use g729 for voice call and send fax in g711ulaw passthru mode.
During a fax call what we have noticed is that when the ATA sends a reinvite with g711ulaw as its codec to Asterisk. Asterisk does not forward this reinvite to SIP GWY and so the RTP from SIP GWY to ATA never change to g711ulaw and fax fails.
How can we overcome this situation.
in the attached image .28 is ATA, .20 is Asterisk and .11 is SIP GWY. In the flow chart, packet at 33.992 is the reinvite packet with media attribute ulaw from ATA
Simple answer this is not 1 call its 2 one from the ata to asterisk and one from asterisk to the ATA in most cases. the call is transcoded in the middle by asterisk
if these are internal why are you using G729 ? or are they external links ?
The link between ATA and Asterisk uses satellite link where bandwidth is very expensive. So g729 is prefered codec for voice call. When user occasionaly sends fax we want it to switch it to g711ulaw.
I would say this was a rather fluid area in Asterisk, and is arguably flawed.
In particular, I have a feeling that Asterisk will never negotiate a wider choice of codecs than the last choice that it negotiated for the same dialogue, so, if the initial negotiation ended up with only G.729, I believe that Asterisk can never be re-invited to use more than G.729. If this is correct, it can be argued that is is a policy choice for Asterisk, not a violation of the SDP negotiation rules.
In any case:
changing codecs should not require a re-invite, as you can switch between the negotiated codecs at the RTP level, so if that was the intention, you should have negotiated a choice of both codecs on the initial invite.
there is a specific way of handling fax over RTP that uses a fax media stream, and I think, raw binary. Asterisk has some support for this, although I have no practical experience.