Outbound call, softmodem and forcing the use of a codec

ludojoey · March 15, 2024, 2:08pm

Hello,

I am on a project that make an outbound call with AMI, then, when conection is established, the called user (in fact a modem) is connected to an extension that will connect the called modem to my modem (Asterisk softmodem).

My problem is the softmodem does not detect the tone of the users’ modem if the codec used is not alaw or ulaw.

Here is my endpoint config:

[ovh2]
type=endpoint
transport=transport-udp-nat
context=test
disallow=all
allow=alaw,ulaw
outbound_auth=ovh2
rtp_symmetric=yes
force_rport=yes
tos_audio = 0xB8
cos_audio = 6
aors=ovh2
from_user=0033XXXXXX
;incoming_call_offer_pref=local
preferred_codec_only=yes

Originating call is made with AMI action Originate with parameter:
Codecs : alaw,ulaw

When called number is reached, it is connected to this extension:

[extcall]
exten => 999,1,Verbose(APPEL ${CALLED})
same => n,Set(VOLUME(TX)=2) 
same => n,Set(VOLUME(RX)=7)
same => n,Set(__SIP_CODEC=alaw)
same => n,Set(__SIP_CODEC_INBOUND=alaw)
same => n,Answer()
same => n,Wait(1)
same => n,SoftmodemTest("127.0.0.1", 8183, "TO ${CALLED}","${PID}", ft(-28))
same => n,Hangup()

No problem with the outbound call and connect it to the extension and modem app.

Sometimes (often), ther softmodem won’t detect the tone of the user’s modem. In that case CLI command “channelstats” display:

ovh2-00000000 00:00:16 slin 445 0 0 0.000 668 0 0 0.001 0.00 0

Sometimes (most of the time), on the same number called, softmodem will detect successfully the tone of the user’s modem. In that case the CLI command “channelstats” will display:

ovh2-00000010 00:00:21 ulaw 158 0 0 0.000 240 0 0 0.001 0.00 0

That’s why I guess it’s a Codec issue.

At first, I thought it was a problem of signal strength of the users’ modem.
I recorded the stream and analyzed it. Strength and frequencies are ok.

Any idea why sometimes slin codec is used, other time alaw/ulaw ?

And how to “force” alaw/ulaw codec?

Thanks !

Ps:

Also tried this in asterisk.conf:

transcode_via_sln = no

but I don’t know if it’s relevant. In any case, it doesn’t change anything…

david551 · March 15, 2024, 2:18pm

A-law to slin is lossless and A-law to slin to A-law is also lossless. Similarly replacing A by µ.

A-law to slin to µ-law is lossy, but no more lossy than A-law to µ-law, which is actually implemented as A-law to slin to µ-law. Similarly the other way. This is loss is what you would have expected on a transatlantic PCM voice call.

I don’t think the codec is an issue here, although, unless you are dealing with multiple continents, I’d suggest you should only use the G.711 codec for your country.

I’d expect any modem to, internally, do an A/µ-law to slin transcode before actually trying to demodulate.

ludojoey · March 15, 2024, 2:29pm

Thanks for replying.

Anyway, when “slin” is used, the softmodem (using spandsl library) doesn’t demodulate.

That’s why I would have like forcing to transcode to alaw codec (I am in Europe)… And still doesn’t understand why sometimes it uses alaw and sometimes slin (not in my codecs…). My tests are made calling a user modem in the same country.

jcolp · March 15, 2024, 2:32pm

What version of Asterisk? What does “core show channel” show? What does the SIP trace of the call show?

ludojoey · March 15, 2024, 2:43pm

Thanks for your reply.

I use Asterisk 21, and for the softmodem , the spandsl lib 3.0.0 (uploaded today to reinstall, in cqse of…)

 -- General --
           Name: PJSIP/ovh2-0000000d
           Type: PJSIP
       UniqueID: 1710513428.24
       LinkedID: 1710513428.24
      Caller ID: (N/A)
 Caller ID Name: MiniPavi
Connected Line ID: (N/A)
Connected Line ID Name: MiniPavi
Eff. Connected Line ID: (N/A)
Eff. Connected Line ID Name: MiniPavi
    DNID Digits: (N/A)
       Language: en
          State: Up (6)
  NativeFormats: (ulaw)
    WriteFormat: slin
     ReadFormat: ulaw
 WriteTranscode: Yes (slin@8000)->(ulaw@8000)
  ReadTranscode: Yes (slin@8000)->(ulaw@8000)
 Time to Hangup: 0
   Elapsed Time: 0h0m47s
      Bridge ID: (Not bridged)
 --   PBX   --
        Context: extcall
      Extension: 999
       Priority: 9
     Call Group: 0
   Pickup Group: 0
    Application: SoftmodemMinipavi
           Data: "127.0.0.1", 8183, "TO 0358435150","9400", ft(-28)
 Call Identifer: [C-0000000c]
      Variables:
MIXMONITOR_FILENAME=/home/ludojoey/miniPavi/recordings/testmodem.wav
SIP_CODEC_INBOUND=alaw
SIP_CODEC=alaw
CALLED=0358435150
PID=9400
  CDR Variables:
level 1: clid="MiniPavi" <>
level 1: dst=999
level 1: dcontext=extcall
level 1: channel=PJSIP/ovh2-0000000d
level 1: lastapp=SoftmodemMinipavi
level 1: lastdata="127.0.0.1", 8183, "TO 0358435150","9400", ft(-28)
level 1: start=1710513428.092623
level 1: answer=1710513429.460867
level 1: end=0.000000
level 1: duration=47
level 1: billsec=46
level 1: disposition=8
level 1: amaflags=3
level 1: uniqueid=1710513428.24
level 1: linkedid=1710513428.24
level 1: sequence=13

 -- Streams --
Name: audio-0
    Type: audio
    State: sendrecv
    Group: -1
    Formats: (alaw|ulaw)
    Metadata:

minipavi*CLI> pjsip show channelstats

                                             ...........Receive......... .........Transmit..........
 BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
 ===========================================================================================================

          ovh2-0000000d      00:00:56 slin     1815       0    0   0.000   2723       0    0   0.001   0.000

And the SIP trace (really not a specialist in SIP protocol!):


<--- Received SIP request (408 bytes) from UDP:91.121.129.134:5060 --->
OPTIONS sip:s@81.36.32.190:5060;line=nhdrlrc SIP/2.0
Call-ID: 00-08040-3def79114-4b3f594a@91.121.129.134
Contact: <sip:91.121.129.134:5060>
CSeq: 1 OPTIONS
From: <sip:keepalive@91.121.129.134:5060>;tag=00-08040-3def79113-21eaeef6
Max-Forwards: 70
To: <sip:0033972101721:6909959AbC@sbc6.fr.sip.ovh>
Via: SIP/2.0/UDP 91.121.129.134:5060;rport;branch=z9hG4bK-DLAH-974ddbda-14c66d64
Content-Length: 0


<--- Transmitting SIP response (890 bytes) to UDP:91.121.129.134:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 91.121.129.134:5060;rport=5060;received=91.121.129.134;branch=z9hG4bK-DLAH-974ddbda-14c66d64
Call-ID: 00-08040-3def79114-4b3f594a@91.121.129.134
From: <sip:keepalive@91.121.129.134>;tag=00-08040-3def79113-21eaeef6
To: <sip:0033972101721:6909959AbC@sbc6.fr.sip.ovh>;tag=z9hG4bK-DLAH-974ddbda-14c66d64
CSeq: 1 OPTIONS
Accept: application/sdp, application/pidf+xml, application/xpidf+xml, application/cpim-pidf+xml, application/dialog-info+xml, application/simple-message-summary, application/simple-message-summary, application/pidf+xml, application/dialog-info+xml, message/sipfrag;version=2.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Accept-Encoding: identity
Accept-Language: en
Server: Asterisk PBX 21.0.0
Content-Length:  0


<--- Received SIP request (408 bytes) from UDP:91.121.129.134:5060 --->
OPTIONS sip:s@81.36.32.190:5060;line=vdjbcbg SIP/2.0
Call-ID: 00-02390-3def8248e-79300d02@91.121.129.134
Contact: <sip:91.121.129.134:5060>
CSeq: 1 OPTIONS
From: <sip:keepalive@91.121.129.134:5060>;tag=00-02390-3def8248d-45ff82a8
Max-Forwards: 70
To: <sip:0033972145674:6909959AbC@sbc6.fr.sip.ovh>
Via: SIP/2.0/UDP 91.121.129.134:5060;rport;branch=z9hG4bK-HSYW-974e4915-1702acb7
Content-Length: 0


<--- Transmitting SIP response (890 bytes) to UDP:91.121.129.134:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 91.121.129.134:5060;rport=5060;received=91.121.129.134;branch=z9hG4bK-HSYW-974e4915-1702acb7
Call-ID: 00-02390-3def8248e-79300d02@91.121.129.134
From: <sip:keepalive@91.121.129.134>;tag=00-02390-3def8248d-45ff82a8
To: <sip:0033972145674:6909959AbC@sbc6.fr.sip.ovh>;tag=z9hG4bK-HSYW-974e4915-1702acb7
CSeq: 1 OPTIONS
Accept: application/sdp, application/pidf+xml, application/xpidf+xml, application/cpim-pidf+xml, application/dialog-info+xml, applica                                                                                                        tion/simple-message-summary, application/simple-message-summary, application/pidf+xml, application/dialog-info+xml, message/sipfrag;v                                                                                                        ersion=2.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Accept-Encoding: identity
Accept-Language: en
Server: Asterisk PBX 21.0.0
Content-Length:  0


<--- Received SIP request (408 bytes) from UDP:91.121.129.134:5060 --->
OPTIONS sip:s@81.36.32.190:5060;line=nhdrlrc SIP/2.0
Call-ID: 00-03327-3def844b3-100fa413@91.121.129.134
Contact: <sip:91.121.129.134:5060>
CSeq: 1 OPTIONS
From: <sip:keepalive@91.121.129.134:5060>;tag=00-03327-3def844b2-6ed1024c
Max-Forwards: 70
To: <sip:0033972101721:6909959AbC@sbc6.fr.sip.ovh>
Via: SIP/2.0/UDP 91.121.129.134:5060;rport;branch=z9hG4bK-EWCK-974e6189-7a84ddde
Content-Length: 0


<--- Transmitting SIP response (890 bytes) to UDP:91.121.129.134:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 91.121.129.134:5060;rport=5060;received=91.121.129.134;branch=z9hG4bK-EWCK-974e6189-7a84ddde
Call-ID: 00-03327-3def844b3-100fa413@91.121.129.134
From: <sip:keepalive@91.121.129.134>;tag=00-03327-3def844b2-6ed1024c
To: <sip:0033972101721:6909959AbC@sbc6.fr.sip.ovh>;tag=z9hG4bK-EWCK-974e6189-7a84ddde
CSeq: 1 OPTIONS
Accept: application/sdp, application/pidf+xml, application/xpidf+xml, application/cpim-pidf+xml, application/dialog-info+xml, applica                                                                                                        tion/simple-message-summary, application/simple-message-summary, application/pidf+xml, application/dialog-info+xml, message/sipfrag;v                                                                                                        ersion=2.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Accept-Encoding: identity
Accept-Language: en
Server: Asterisk PBX 21.0.0
Content-Length:  0


<--- Transmitting SIP request (948 bytes) to UDP:91.121.129.134:5060 --->
INVITE sip:0358435150@sbc6.fr.sip.ovh SIP/2.0
Via: SIP/2.0/UDP 81.36.32.190:5060;rport;branch=z9hG4bKPj7fb01f03-b91a-4245-b5d8-915636b5e3ea
From: <sip:0033972145674@192.168.1.55>;tag=3364070e-7481-4d2b-be15-12ec7913517c
To: <sip:0358435150@sbc6.fr.sip.ovh>
Contact: <sip:0033972145674@81.36.32.190:5060>
Call-ID: e9fb88bc-a5c3-4e70-b5e6-45e4ec4aac6b
CSeq: 27970 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 21.0.0
Content-Type: application/sdp
Content-Length:   261

v=0
o=- 1163274665 1163274665 IN IP4 81.36.32.190
s=Asterisk
c=IN IP4 81.36.32.190
t=0 0
m=audio 10002 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Received SIP response (349 bytes) from UDP:91.121.129.134:5060 --->
SIP/2.0 100 Trying
Call-ID: e9fb88bc-a5c3-4e70-b5e6-45e4ec4aac6b
CSeq: 27970 INVITE
From: <sip:0033972145674@192.168.1.55>;tag=3364070e-7481-4d2b-be15-12ec7913517c
To: <sip:0358435150@sbc6.fr.sip.ovh>
Via: SIP/2.0/UDP 81.36.32.190:5060;received=81.36.32.190;rport=5060;branch=z9hG4bKPj7fb01f03-b91a-4245-b5d8-915636b5e3ea
Content-Length: 0


<--- Received SIP response (795 bytes) from UDP:91.121.129.134:5060 --->
SIP/2.0 407 authentication required
Call-ID: e9fb88bc-a5c3-4e70-b5e6-45e4ec4aac6b
Contact: <sip:0358435150@91.121.129.134:5060;user=phone>
CSeq: 27970 INVITE
From: <sip:0033972145674@192.168.1.55>;tag=3364070e-7481-4d2b-be15-12ec7913517c
Proxy-Authenticate: Digest realm="sbc6.fr.sip.ovh",nonce="3feaea593359832a28bc450c3e4baa3c",opaque="3fd519df37076b7",stale=false,algo                                                                                                        rithm=MD5
Record-Route: <sip:91.121.129.134:5060;transport=udp;lr>;session=347951
To: <sip:0358435150@sbc6.fr.sip.ovh>;tag=00-08000-3feaf803-43d872fa0
Via: SIP/2.0/UDP 81.36.32.190:5060;received=81.36.32.190;rport=5060;branch=z9hG4bKPj7fb01f03-b91a-4245-b5d8-915636b5e3ea
Allow: REFER,INVITE,NOTIFY,ACK,UPDATE,OPTIONS,REGISTER,SUBSCRIBE,NOTIFY,CANCEL,BYE,PRACK
Server: Cirpack/v4.76 (gw_sip)
Content-Length: 0


<--- Transmitting SIP request (427 bytes) to UDP:91.121.129.134:5060 --->
ACK sip:0358435150@sbc6.fr.sip.ovh SIP/2.0
Via: SIP/2.0/UDP 81.36.32.190:5060;rport;branch=z9hG4bKPj7fb01f03-b91a-4245-b5d8-915636b5e3ea
From: <sip:0033972145674@192.168.1.55>;tag=3364070e-7481-4d2b-be15-12ec7913517c
To: <sip:0358435150@sbc6.fr.sip.ovh>;tag=00-08000-3feaf803-43d872fa0
Call-ID: e9fb88bc-a5c3-4e70-b5e6-45e4ec4aac6b
CSeq: 27970 ACK
Max-Forwards: 70
User-Agent: Asterisk PBX 21.0.0
Content-Length:  0


<--- Transmitting SIP request (1193 bytes) to UDP:91.121.129.134:5060 --->
INVITE sip:0358435150@sbc6.fr.sip.ovh SIP/2.0
Via: SIP/2.0/UDP 81.36.32.190:5060;rport;branch=z9hG4bKPjc0c950b7-b589-4f87-aaee-d9101d58c968
From: <sip:0033972145674@192.168.1.55>;tag=3364070e-7481-4d2b-be15-12ec7913517c
To: <sip:0358435150@sbc6.fr.sip.ovh>
Contact: <sip:0033972145674@81.36.32.190:5060>
Call-ID: e9fb88bc-a5c3-4e70-b5e6-45e4ec4aac6b
CSeq: 27971 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 21.0.0
Proxy-Authorization: Digest username="0033972145674", realm="sbc6.fr.sip.ovh", nonce="3feaea593359832a28bc450c3e4baa3c", uri="sip:035                                                                                                        8435150@sbc6.fr.sip.ovh", response="98f029529d8fe7caadc82d397f579d8a", algorithm=MD5, opaque="3fd519df37076b7"
Content-Type: application/sdp
Content-Length:   261

v=0
o=- 1163274665 1163274665 IN IP4 81.36.32.190
s=Asterisk
c=IN IP4 81.36.32.190
t=0 0
m=audio 10002 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Received SIP response (349 bytes) from UDP:91.121.129.134:5060 --->
SIP/2.0 100 Trying
Call-ID: e9fb88bc-a5c3-4e70-b5e6-45e4ec4aac6b
CSeq: 27971 INVITE
From: <sip:0033972145674@192.168.1.55>;tag=3364070e-7481-4d2b-be15-12ec7913517c
To: <sip:0358435150@sbc6.fr.sip.ovh>
Via: SIP/2.0/UDP 81.36.32.190:5060;received=81.36.32.190;rport=5060;branch=z9hG4bKPjc0c950b7-b589-4f87-aaee-d9101d58c968
Content-Length: 0


<--- Received SIP response (920 bytes) from UDP:91.121.129.134:5060 --->
SIP/2.0 180 Ringing
Call-ID: e9fb88bc-a5c3-4e70-b5e6-45e4ec4aac6b
Contact: <sip:91.121.129.134:5060>
Content-Type: application/sdp
CSeq: 27971 INVITE
From: <sip:0033972145674@192.168.1.55>;tag=3364070e-7481-4d2b-be15-12ec7913517c
Record-Route: <sip:91.121.129.134:5060;transport=udp;lr>;session=347959
To: <sip:0358435150@sbc6.fr.sip.ovh>;tag=00-08172-3feaf80e-3d4a05c94
Via: SIP/2.0/UDP 81.36.32.190:5060;received=81.36.32.190;rport=5060;branch=z9hG4bKPjc0c950b7-b589-4f87-aaee-d9101d58c968
Allow: REFER,INVITE,NOTIFY,ACK,UPDATE,OPTIONS,REGISTER,SUBSCRIBE,NOTIFY,CANCEL,BYE,PRACK
Server: Cirpack/v4.76 (gw_sip)
Content-Length: 274

v=0
o=anonymous 171051364063 171051364064 IN IP4 91.121.129.134
s=SIP Call
c=IN IP4 91.121.129.165
t=0 0
m=audio 34296 RTP/AVP 8 0 101
b=AS:82
a=rtpmap:8 PCMA/8000/1
a=rtpmap:0 PCMU/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

<--- Received SIP response (985 bytes) from UDP:91.121.129.134:5060 --->
SIP/2.0 200 OK
Call-ID: e9fb88bc-a5c3-4e70-b5e6-45e4ec4aac6b
Contact: <sip:91.121.129.134:5060>
Content-Type: application/sdp
CSeq: 27971 INVITE
From: <sip:0033972145674@192.168.1.55>;tag=3364070e-7481-4d2b-be15-12ec7913517c
Record-Route: <sip:91.121.129.134:5060;transport=udp;lr>;session=347959
To: <sip:0358435150@sbc6.fr.sip.ovh>;tag=00-08172-3feaf80e-3d4a05c94
Via: SIP/2.0/UDP 81.36.32.190:5060;received=81.36.32.190;rport=5060;branch=z9hG4bKPjc0c950b7-b589-4f87-aaee-d9101d58c968
Allow: REFER,INVITE,NOTIFY,ACK,UPDATE,OPTIONS,REGISTER,SUBSCRIBE,NOTIFY,CANCEL,BYE,PRACK
Server: Cirpack/v4.76 (gw_sip)
P-Asserted-Identity: <sip:0358435150@91.121.129.134:5060;user=phone>
Content-Length: 274

v=0
o=anonymous 171051364063 171051364065 IN IP4 91.121.129.134
s=SIP Call
c=IN IP4 91.121.129.165
t=0 0
m=audio 34296 RTP/AVP 0 8 101
b=AS:77
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv

<--- Transmitting SIP request (486 bytes) to UDP:91.121.129.134:5060 --->
ACK sip:91.121.129.134:5060 SIP/2.0
Via: SIP/2.0/UDP 81.36.32.190:5060;rport;branch=z9hG4bKPj07e40768-f0f4-4c51-9aa9-4ca4708f73fd
From: <sip:0033972145674@192.168.1.55>;tag=3364070e-7481-4d2b-be15-12ec7913517c
To: <sip:0358435150@sbc6.fr.sip.ovh>;tag=00-08172-3feaf80e-3d4a05c94
Call-ID: e9fb88bc-a5c3-4e70-b5e6-45e4ec4aac6b
CSeq: 27971 ACK
Route: <sip:91.121.129.134:5060;transport=udp;lr>;session=347959
Max-Forwards: 70
User-Agent: Asterisk PBX 21.0.0
Content-Length:  0

jcolp · March 15, 2024, 2:46pm

“ulaw” has been negotiated. Something has set the channel to be in “slin” for interacting with it from an application perspective. What that is, no idea. Could be your dialplan application.

ludojoey · March 15, 2024, 2:49pm

Thanks.
Strange… dialplan app doesn’t change betwwen 2 calls…
I just try a new call now, that succeed (tone detected):


minipavi*CLI> pjsip show channelstats

                                             ...........Receive......... .........Transmit..........
 BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
 ===========================================================================================================

          ovh2-0000000f      00:00:20 ulaw      584       0    0   0.000    877       0    0   0.001   0.000

Objects found: 1

minipavi*CLI> core show channel PJSIP/ovh2-0000000f
 -- General --
           Name: PJSIP/ovh2-0000000f
           Type: PJSIP
       UniqueID: 1710513979.28
       LinkedID: 1710513979.28
      Caller ID: (N/A)
 Caller ID Name: MiniPavi
Connected Line ID: (N/A)
Connected Line ID Name: MiniPavi
Eff. Connected Line ID: (N/A)
Eff. Connected Line ID Name: MiniPavi
    DNID Digits: (N/A)
       Language: en
          State: Up (6)
  NativeFormats: (ulaw)
    WriteFormat: slin
     ReadFormat: slin
 WriteTranscode: Yes (slin@8000)->(ulaw@8000)
  ReadTranscode: Yes (ulaw@8000)->(slin@8000)
 Time to Hangup: 0
   Elapsed Time: 0h0m30s
      Bridge ID: (Not bridged)
 --   PBX   --
        Context: extcall
      Extension: 999
       Priority: 9
     Call Group: 0
   Pickup Group: 0
    Application: SoftmodemMinipavi
           Data: "127.0.0.1", 8183, "TO 0358435150","9400", ft(-28)
 Call Identifer: [C-0000000e]
      Variables:
MIXMONITOR_FILENAME=/home/ludojoey/miniPavi/recordings/testmodem.wav
SIP_CODEC_INBOUND=alaw
SIP_CODEC=alaw
CALLED=0358435150
PID=9400
  CDR Variables:
level 1: clid="MiniPavi" <>
level 1: dst=999
level 1: dcontext=extcall
level 1: channel=PJSIP/ovh2-0000000f
level 1: lastapp=SoftmodemMinipavi
level 1: lastdata="127.0.0.1", 8183, "TO 0358435150","9400", ft(-28)
level 1: start=1710513979.702543
level 1: answer=1710513980.853267
level 1: end=0.000000
level 1: duration=29
level 1: billsec=28
level 1: disposition=8
level 1: amaflags=3
level 1: uniqueid=1710513979.28
level 1: linkedid=1710513979.28
level 1: sequence=15

 -- Streams --
Name: audio-0
    Type: audio
    State: sendrecv
    Group: -1
    Formats: (ulaw)
    Metadata:
minipavi*CLI>
minipavi*CLI>
minipavi*CLI> core show channel PJSIP/ovh2-0000000f
 -- General --
           Name: PJSIP/ovh2-0000000f
           Type: PJSIP
       UniqueID: 1710513979.28
       LinkedID: 1710513979.28
      Caller ID: (N/A)
 Caller ID Name: MiniPavi
Connected Line ID: (N/A)
Connected Line ID Name: MiniPavi
Eff. Connected Line ID: (N/A)
Eff. Connected Line ID Name: MiniPavi
    DNID Digits: (N/A)
       Language: en
          State: Up (6)
  NativeFormats: (ulaw)
    WriteFormat: slin
     ReadFormat: slin
 WriteTranscode: Yes (slin@8000)->(ulaw@8000)
  ReadTranscode: Yes (ulaw@8000)->(slin@8000)
 Time to Hangup: 0
   Elapsed Time: 0h0m34s
      Bridge ID: (Not bridged)
 --   PBX   --
        Context: extcall
      Extension: 999
       Priority: 9
     Call Group: 0
   Pickup Group: 0
    Application: SoftmodemMinipavi
           Data: "127.0.0.1", 8183, "TO 0358435150","9400", ft(-28)
 Call Identifer: [C-0000000e]
      Variables:
MIXMONITOR_FILENAME=/home/ludojoey/miniPavi/recordings/testmodem.wav
SIP_CODEC_INBOUND=alaw
SIP_CODEC=alaw
CALLED=0358435150
PID=9400
  CDR Variables:
level 1: clid="MiniPavi" <>
level 1: dst=999
level 1: dcontext=extcall
level 1: channel=PJSIP/ovh2-0000000f
level 1: lastapp=SoftmodemMinipavi
level 1: lastdata="127.0.0.1", 8183, "TO 0358435150","9400", ft(-28)
level 1: start=1710513979.702543
level 1: answer=1710513980.853267
level 1: end=0.000000
level 1: duration=34
level 1: billsec=32
level 1: disposition=8
level 1: amaflags=3
level 1: uniqueid=1710513979.28
level 1: linkedid=1710513979.28
level 1: sequence=15

 -- Streams --
Name: audio-0
    Type: audio
    State: sendrecv
    Group: -1
    Formats: (ulaw)
    Metadata:
minipavi*CLI>

I am going to investigate!

Also, I suspect something related to the other users VoIP line configuration because the issue only occur when I call certain numbers. Others always work well with always using alaw codec.

david551 · March 15, 2024, 2:56pm

Assuming it is this app, it only works in SLIN, which is what I’d expect, as the digital signal processing needs to be done on linear data:

github.com

proquar/asterisk-Softmodem/blob/14e5b4f9ebbd8dcbf107a397e26b5385771bdff7/app_softmodem.c#L361-L365


      
          	struct ast_frame outf = {
          		.frametype = AST_FRAME_VOICE,
          		.subclass.format = ast_format_slin,
          		.src = __FUNCTION__,
          	};

There are no hits for ulaw or alaw in the code.

ludojoey · March 15, 2024, 3:29pm

Yes, it is mainly base on this app.

Well… So I really don’t understand why it doesn’t work when Asterisk shows this:

ovh2-0000000d 00:00:56 slin 1815 0 0 0.000 2723 0 0 0.001 0.000

and works when it shows that:

ovh2-0000000f 00:00:20 ulaw 584 0 0 0.000 877 0 0 0.001 0.000

Should be the opposite, no?

ludojoey · March 15, 2024, 3:57pm

Well, I think I have solved my problem!

I added in mydialplan:

same => n,Set(MASTER_CHANNEL(PJSIP_MEDIA_OFFER(audio))=!all,alaw)
same => n,Set(MASTER_CHANNEL(PJSIP_SEND_SESSION_REFRESH())=invite)

Now, all connection succeed, modem tone is detected at each call.

Thanks to those who replied me and now I know a little more about codecs!

PS: still wondering why I have to force alaw codec, if the app use slin codec…

david551 · March 15, 2024, 4:20pm

You were negotiation µ-law in an A-law country, so may have had some degradation as a result, but I wouldn’t have expected this to be enough to break relatively low speed modems.

system · April 14, 2024, 4:21pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Codec madness: all except alaw disabled yet "Unable to find a codec translation path: (g729) -> (alaw)" Asterisk SIP	11	9169	May 7, 2020
Asterisk 11 : Audio Issue : Codec Translation Asterisk Support	4	338	November 26, 2012
Does Asterisk Translate Ulaw to G722 Asterisk Support	17	2985	March 14, 2016
[RESOLVED] Conversion between codecs (can't get it working) Asterisk Support	5	1679	November 15, 2013
Playback application choose wrong (highest translation cost) format Asterisk Support	4	489	December 1, 2019

Outbound call, softmodem and forcing the use of a codec

Related topics