Movistar Sip Mexico

Home » Asterisk Users » Movistar Sip Mexico
Asterisk Users 12 Comments

Hello,

I have a problem with movistar in Mexico with a sip calls. Movistar send to me T38 and G729 in the INVITE and they say that I have to ignore T38 and use G729 in the voice call.

When a fax call is made Movistar send only T38 in the INVITE.

Invite example:

v=0
o=GDL-BMSW-12D 19913379 19899826 IN IP4 192.168.1.2
s=sip call c=IN IP4 192.168.1.2
t=0 0
m=audio 6370 RTP/AVP 18 101
a=fmtp:18 annexb=yes a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
m=image 6372 udptl t38
a=T38FaxVersion:0
a=T38FaxMaxBuffer:1100
a=T38FaxMaxDatagram:612
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy

How can I ignore T38 and use only G729 for this call?.

Thanks for your help.

Damian

12 thoughts on - Movistar Sip Mexico

  • Think you only need to make sure you have in your sip.conf file these configs:

    [your-device-name]
    …..
    ….. disallow=all allow=g729
    …..
    …..

    Alyed

    2013/11/20 Damian Gonzalez

  • Hello,

    Thanks for the quickly response. I have only G729 in the peer but I have t38pt_udptl= yes

    If I put t38pt_udptl=no , asterisk reject the call with 488 code.

    The problem is that Movistar send T38 codec in all calls and I need ignore only if in the SDP I have G729 and T38 (18 and 101), but if I have only T38
    I have to negociate a fax call.

    Thanks.

  • It is possible that Asterisk requires an rtpmap even for static payload types (I’m not sure about this). The INVITE from your provider omits rtpmap for payload type 18 (G729) which is perfectly valid.

  • Can you funnel them through a specific inbound dial context. Then force a re-invite to g729?

    Thanks

    Bryant Zimmerman (ZK Tech Inc.)
    616-855-1030 Ext. 2003

    ————————————–

  • Hi,

    I have Asterisk 10.12.1. I can not figure out the solution.

    Thank you for your help.

    Best Regards

  • My understanding of the original posting is that when a voice call arrives from the SIP provider it includes T38 information though the user only wants to accept the g729 component of the call and carry out a voice conversation.

    If a fax is being received by the SIP provider it only has a the T38
    information for the call thus no audio (g729) information is in the SIP
    message.

    I don’t believe the original poster is attempting to receive a facsimile, instead use voice calls.

    Larry.

  • I have had the same problem with a carrier, where some calls we receive from them have an image and an audio stream in the initial INVITE, even though the call is intended to use the audio stream. Responding back accepting T.38 will fail and *all* other options trying to reject the T.38 using known SIP supported methods will also fail. The *only* option is to just ignore the image stream, which is not allowed by the current set of SIP RFCs…

    Asterisk used to ignore the image stream, but since the 1.8(?) timeframe its behaviour has changed more towards standards compliance in this area. And now we’re between a rock and a hard place.

    The only way out that I could find is to put something in front of Asterisk that just removes the image stream from initial INVITEs when received from the carrier. (OpenSIPS has this nice method called remove_stream() since a couple of versions)

    Complaining about this didn’t help, “Asterisk is not certified because Open Source”, was basically their answer.