cellular-infrastructure
/
osmocom-analog
9
1
Fork 2
Code Issues 11 Pull Requests 2 Projects Releases Wiki Activity

Codec L16/8000 (slin) do not work #21

New Issue
Closed
opened 2024-01-26 20:17:14 +00:00 by shadowcaster3 · 3 comments
shadowcaster3 commented 2024-01-26 20:17:14 +00:00
Collaborator
Copy Link

As per 6cd2c3e323/src/libmobile/call.c (L94) codec L16/8000 should be supported, but attempt to actually use it ends up in following message: "No codec found in setup message that we support."

please see attached debug log.

2024-01-26 22:12:32.050 socket.c 203 cc-debug : New socket connection (callref 3).
2024-01-26 22:12:32.050 endpoint.c 43 cc-debug : Creating new call with callref 3.
2024-01-26 22:12:32.050 endpoint.c 964 cc-info : Handle message CC-SETUP-REQ at state IDLE (callref 3)
2024-01-26 22:12:32.050 message.c 526 cc-info : IE_CALLING_NETWORK type=4(sip) id=''
2024-01-26 22:12:32.050 message.c 520 cc-info : IE_CALLING_INTERFACE name='sip'
2024-01-26 22:12:32.050 message.c 586 cc-info : IE_SDP payload=v=0\no=- 1894188585 1894188585 IN IP4 127.0.0.1\ns=Asterisk\nc=IN IP4 127.0.0.1\nt=0 0\nm=audio 18966 RTP/AVP 10 101\na=rtpmap:10 L16/8000\na=rtpmap:101 telephone-event/8000\na=fmtp:101 0-16\na=ptime:20\na=maxptime:60\na=sendrecv\n
2024-01-26 22:12:32.050 message.c 502 cc-info : IE_CALLING type=0(unknown) plan=1(telephony), presentation=0(allowed), screening=3(network provided), number='611'
2024-01-26 22:12:32.050 message.c 514 cc-info : IE_CALLING_NAME name='"Phone 611"'
2024-01-26 22:12:32.050 message.c 472 cc-info : IE_CALLED type=0(unknown) plan=1(telephony) number='3131110000'
2024-01-26 22:12:32.050 message.c 496 cc-info : IE_COMPLETE
2024-01-26 22:12:32.050 message.c 520 cc-info : IE_CALLING_INTERFACE name='sip'
2024-01-26 22:12:32.050 endpoint.c 108 cc-debug : Changing call state with callref 3 from IDLE to INIT-OUT.
2024-01-26 22:12:32.050 session.c 362 cc-debug : Parsing session offer.
2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | v=0
2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | o=- 1894188585 1894188585 IN IP4 127.0.0.1
2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | s=Asterisk
2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | c=IN IP4 127.0.0.1
2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | t=0 0
2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | m=audio 18966 RTP/AVP 10 101
2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | a=rtpmap:10 L16/8000
2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | a=rtpmap:101 telephone-event/8000
2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | a=fmtp:101 0-16
2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | a=ptime:20
2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | a=maxptime:60
2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | a=sendrecv
2024-01-26 22:12:32.050 sdp.c 306 cc-debug : -> Version: 0
2024-01-26 22:12:32.050 sdp.c 314 cc-debug : -> Originator: - 1894188585 1894188585 IN IP4 127.0.0.1
2024-01-26 22:12:32.050 sdp.c 349 cc-debug : -> Session Name: Asterisk
2024-01-26 22:12:32.050 sdp.c 354 cc-debug : -> Connection Data: IN IP4 127.0.0.1
2024-01-26 22:12:32.050 sdp.c 373 cc-debug : -> Address Type = IPv4
2024-01-26 22:12:32.050 sdp.c 389 cc-debug : -> Address = 127.0.0.1
2024-01-26 22:12:32.050 sdp.c 392 cc-debug : -> Media Description: audio 18966 RTP/AVP 10 101
2024-01-26 22:12:32.050 sdp.c 433 cc-debug : -> payload type = 10
2024-01-26 22:12:32.050 sdp.c 435 cc-debug : -> payload name = L16
2024-01-26 22:12:32.050 sdp.c 437 cc-debug : -> payload rate = 44100
2024-01-26 22:12:32.050 sdp.c 439 cc-debug : -> payload channels = 2
2024-01-26 22:12:32.050 sdp.c 433 cc-debug : -> payload type = 101
2024-01-26 22:12:32.050 sdp.c 443 cc-debug : -> Attribute: rtpmap:10 L16/8000
2024-01-26 22:12:32.050 sdp.c 499 cc-debug : -> (rtpmap) payload type = 10
2024-01-26 22:12:32.050 sdp.c 506 cc-debug : -> (rtpmap) payload name = L16
2024-01-26 22:12:32.050 sdp.c 512 cc-debug : -> (rtpmap) payload rate = 8000
2024-01-26 22:12:32.050 sdp.c 443 cc-debug : -> Attribute: rtpmap:101 telephone-event/8000
2024-01-26 22:12:32.050 sdp.c 499 cc-debug : -> (rtpmap) payload type = 101
2024-01-26 22:12:32.050 sdp.c 506 cc-debug : -> (rtpmap) payload name = telephone-event
2024-01-26 22:12:32.050 sdp.c 512 cc-debug : -> (rtpmap) payload rate = 8000
2024-01-26 22:12:32.050 sdp.c 443 cc-debug : -> Attribute: fmtp:101 0-16
2024-01-26 22:12:32.050 sdp.c 443 cc-debug : -> Attribute: ptime:20
2024-01-26 22:12:32.050 sdp.c 443 cc-debug : -> Attribute: maxptime:60
2024-01-26 22:12:32.050 sdp.c 443 cc-debug : -> Attribute: sendrecv
2024-01-26 22:12:32.050 helper.c 135 cc-error : No codec found in setup message that we support.
2024-01-26 22:12:32.050 session.c 111 cc-debug : Free session structure.
2024-01-26 22:12:32.050 session.c 183 cc-debug : Free session media.
2024-01-26 22:12:32.050 session.c 248 cc-debug : Free session codec.
2024-01-26 22:12:32.050 session.c 248 cc-debug : Free session codec.
2024-01-26 22:12:32.050 call.c 498 call-info : Indicated OSMO-CC release towards fixed network
2024-01-26 22:12:32.050 endpoint.c 964 cc-info : Handle message CC-REJ-IND at state INIT-OUT (callref 3)
2024-01-26 22:12:32.050 message.c 568 cc-info : IE_CAUSE location=1(private network serving local user) isdn_cause=47(resource unavailable) sip_cause=503 socket_cause=0(unset)
2024-01-26 22:12:32.050 endpoint.c 108 cc-debug : Changing call state with callref 3 from INIT-OUT to IDLE.
2024-01-26 22:12:32.050 endpoint.c 62 cc-debug : Destroying call with callref 3.
2024-01-26 22:12:32.050 socket.c 445 cc-debug : closing socket because we sent a release or reject message.
2024-01-26 22:12:32.050 socket.c 231 cc-debug : Destroy socket connection (callref 3).

As per https://gitea.osmocom.org/cellular-infrastructure/osmocom-analog/src/commit/6cd2c3e323b5f8e873d986a78ee56e67e41e242e/src/libmobile/call.c#L94 codec L16/8000 should be supported, but attempt to actually use it ends up in following message: "No codec found in setup message that we support." please see attached debug log. 2024-01-26 22:12:32.050 socket.c 203 cc-debug : New socket connection (callref 3). 2024-01-26 22:12:32.050 endpoint.c 43 cc-debug : Creating new call with callref 3. 2024-01-26 22:12:32.050 endpoint.c 964 cc-info : Handle message CC-SETUP-REQ at state IDLE (callref 3) 2024-01-26 22:12:32.050 message.c 526 cc-info : IE_CALLING_NETWORK type=4(sip) id='' 2024-01-26 22:12:32.050 message.c 520 cc-info : IE_CALLING_INTERFACE name='sip' 2024-01-26 22:12:32.050 message.c 586 cc-info : IE_SDP payload=v=0\no=- 1894188585 1894188585 IN IP4 127.0.0.1\ns=Asterisk\nc=IN IP4 127.0.0.1\nt=0 0\nm=audio 18966 RTP/AVP 10 101\na=rtpmap:10 L16/8000\na=rtpmap:101 telephone-event/8000\na=fmtp:101 0-16\na=ptime:20\na=maxptime:60\na=sendrecv\n 2024-01-26 22:12:32.050 message.c 502 cc-info : IE_CALLING type=0(unknown) plan=1(telephony), presentation=0(allowed), screening=3(network provided), number='611' 2024-01-26 22:12:32.050 message.c 514 cc-info : IE_CALLING_NAME name='"Phone 611"' 2024-01-26 22:12:32.050 message.c 472 cc-info : IE_CALLED type=0(unknown) plan=1(telephony) number='3131110000' 2024-01-26 22:12:32.050 message.c 496 cc-info : IE_COMPLETE 2024-01-26 22:12:32.050 message.c 520 cc-info : IE_CALLING_INTERFACE name='sip' 2024-01-26 22:12:32.050 endpoint.c 108 cc-debug : Changing call state with callref 3 from IDLE to INIT-OUT. 2024-01-26 22:12:32.050 session.c 362 cc-debug : Parsing session offer. 2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | v=0 2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | o=- 1894188585 1894188585 IN IP4 127.0.0.1 2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | s=Asterisk 2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | c=IN IP4 127.0.0.1 2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | t=0 0 2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | m=audio 18966 RTP/AVP 10 101 2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | a=rtpmap:10 L16/8000 2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | a=rtpmap:101 telephone-event/8000 2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | a=fmtp:101 0-16 2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | a=ptime:20 2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | a=maxptime:60 2024-01-26 22:12:32.050 sdp.c 551 cc-debug : | a=sendrecv 2024-01-26 22:12:32.050 sdp.c 306 cc-debug : -> Version: 0 2024-01-26 22:12:32.050 sdp.c 314 cc-debug : -> Originator: - 1894188585 1894188585 IN IP4 127.0.0.1 2024-01-26 22:12:32.050 sdp.c 349 cc-debug : -> Session Name: Asterisk 2024-01-26 22:12:32.050 sdp.c 354 cc-debug : -> Connection Data: IN IP4 127.0.0.1 2024-01-26 22:12:32.050 sdp.c 373 cc-debug : -> Address Type = IPv4 2024-01-26 22:12:32.050 sdp.c 389 cc-debug : -> Address = 127.0.0.1 2024-01-26 22:12:32.050 sdp.c 392 cc-debug : -> Media Description: audio 18966 RTP/AVP 10 101 2024-01-26 22:12:32.050 sdp.c 433 cc-debug : -> payload type = 10 2024-01-26 22:12:32.050 sdp.c 435 cc-debug : -> payload name = L16 2024-01-26 22:12:32.050 sdp.c 437 cc-debug : -> payload rate = 44100 2024-01-26 22:12:32.050 sdp.c 439 cc-debug : -> payload channels = 2 2024-01-26 22:12:32.050 sdp.c 433 cc-debug : -> payload type = 101 2024-01-26 22:12:32.050 sdp.c 443 cc-debug : -> Attribute: rtpmap:10 L16/8000 2024-01-26 22:12:32.050 sdp.c 499 cc-debug : -> (rtpmap) payload type = 10 2024-01-26 22:12:32.050 sdp.c 506 cc-debug : -> (rtpmap) payload name = L16 2024-01-26 22:12:32.050 sdp.c 512 cc-debug : -> (rtpmap) payload rate = 8000 2024-01-26 22:12:32.050 sdp.c 443 cc-debug : -> Attribute: rtpmap:101 telephone-event/8000 2024-01-26 22:12:32.050 sdp.c 499 cc-debug : -> (rtpmap) payload type = 101 2024-01-26 22:12:32.050 sdp.c 506 cc-debug : -> (rtpmap) payload name = telephone-event 2024-01-26 22:12:32.050 sdp.c 512 cc-debug : -> (rtpmap) payload rate = 8000 2024-01-26 22:12:32.050 sdp.c 443 cc-debug : -> Attribute: fmtp:101 0-16 2024-01-26 22:12:32.050 sdp.c 443 cc-debug : -> Attribute: ptime:20 2024-01-26 22:12:32.050 sdp.c 443 cc-debug : -> Attribute: maxptime:60 2024-01-26 22:12:32.050 sdp.c 443 cc-debug : -> Attribute: sendrecv 2024-01-26 22:12:32.050 helper.c 135 cc-error : No codec found in setup message that we support. 2024-01-26 22:12:32.050 session.c 111 cc-debug : Free session structure. 2024-01-26 22:12:32.050 session.c 183 cc-debug : Free session media. 2024-01-26 22:12:32.050 session.c 248 cc-debug : Free session codec. 2024-01-26 22:12:32.050 session.c 248 cc-debug : Free session codec. 2024-01-26 22:12:32.050 call.c 498 call-info : Indicated OSMO-CC release towards fixed network 2024-01-26 22:12:32.050 endpoint.c 964 cc-info : Handle message CC-REJ-IND at state INIT-OUT (callref 3) 2024-01-26 22:12:32.050 message.c 568 cc-info : IE_CAUSE location=1(private network serving local user) isdn_cause=47(resource unavailable) sip_cause=503 socket_cause=0(unset) 2024-01-26 22:12:32.050 endpoint.c 108 cc-debug : Changing call state with callref 3 from INIT-OUT to IDLE. 2024-01-26 22:12:32.050 endpoint.c 62 cc-debug : Destroying call with callref 3. 2024-01-26 22:12:32.050 socket.c 445 cc-debug : closing socket because we sent a release or reject message. 2024-01-26 22:12:32.050 socket.c 231 cc-debug : Destroy socket connection (callref 3).
jolly commented 2024-01-26 21:29:53 +00:00
Collaborator
Copy Link

See https://en.wikipedia.org/wiki/RTP_payload_formats
The default for format type 10 is 44100 samplerate and two channels. The Asterisk offers format 10 with samplerate of 8000, but does not specify 1 channel. (rtpmap: 10 L16/8000/1 should be specified). osmocom-analog does not support stereo, also I think that Asterisk assumes one channel only, otherwise your patch would cause bad audio.
Asterisk should use format 10, because it has 1 channel by default. This is obviously a bug in Asterisk. Do you have any other document source that states a default of one channel for format 10?

See https://en.wikipedia.org/wiki/RTP_payload_formats The default for format type 10 is 44100 samplerate and two channels. The Asterisk offers format 10 with samplerate of 8000, but does not specify 1 channel. (rtpmap: 10 L16/8000/1 should be specified). osmocom-analog does not support stereo, also I think that Asterisk assumes one channel only, otherwise your patch would cause bad audio. Asterisk should use format 10, because it has 1 channel by default. This is obviously a bug in Asterisk. Do you have any other document source that states a default of one channel for format 10?
shadowcaster3 commented 2024-01-26 21:47:02 +00:00
Author
Collaborator
Copy Link

Well, technically neither of this format IDs should be used. Why asterisk chooses 10/stereo and would it be better if it choose 11/mono?
Numbers in asterisk are defined here
f4845f756f/main/rtp_engine.c (L3724)

Both RFC 3551 table 4 (https://datatracker.ietf.org/doc/html/rfc3551) and much older RFC 1810 table 2 (https://datatracker.ietf.org/doc/html/rfc1890) don't define L16/8000 as a proper payload type, so in theory it should be dynamic (type from dynamic range).

Asterisk also defines slin44 as L16/44000 instead of 44100 (I opened issue https://github.com/asterisk/asterisk/issues/555 but doubt that it will ever be resolved as nobody probably uses that format).
They also define this payload type as number 125. Why? Probably because in RFC3555 page 20 we see "For non-RTP transport, the permissible values for rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100, and 48000 samples per second. For RTP transport, other values are permissible but the aforementioned values are RECOMMENDED." so technically asterisk team is correct by defining own sample rate for RTP payload and assigning it some custom number.

Summary: I'm not sure what payload id should be used or correct for L16/8000 according to RFC. Not the best fix, and probably payload type for L16 should be more permissive when selecting codecs.

Well, technically neither of this format IDs should be used. Why asterisk chooses 10/stereo and would it be better if it choose 11/mono? Numbers in asterisk are defined here https://github.com/asterisk/asterisk/blob/f4845f756f27952eb16229abcc930c4b16b0e884/main/rtp_engine.c#L3724 Both RFC 3551 table 4 (https://datatracker.ietf.org/doc/html/rfc3551) and much older RFC 1810 table 2 (https://datatracker.ietf.org/doc/html/rfc1890) don't define L16/8000 as a proper payload type, so in theory it should be dynamic (type from dynamic range). Asterisk also defines slin44 as L16/44000 instead of 44100 (I opened issue https://github.com/asterisk/asterisk/issues/555 but doubt that it will ever be resolved as nobody probably uses that format). They also define this payload type as number 125. Why? Probably because in RFC3555 page 20 we see "For non-RTP transport, the permissible values for rate are 8000, 11025, 16000, 22050, 24000, 32000, 44100, and 48000 samples per second. For RTP transport, other values are permissible but the aforementioned values are RECOMMENDED." so technically asterisk team is correct by defining own sample rate for RTP payload and assigning it some custom number. Summary: I'm not sure what payload id should be used or correct for L16/8000 according to RFC. Not the best fix, and probably payload type for L16 should be more permissive when selecting codecs.
jolly was assigned by laforge 2024-02-16 14:07:25 +00:00
jolly commented 2024-02-18 17:52:26 +00:00
Collaborator
Copy Link

After reading specs and having long conversation with Chat-GPT, I came up with a fix that should work with Asterisk now. The fix is pushed to libosmo-cc.

SDP: Fix interpretation of number of channels within rtpmap

The standard says (RFC 4566 / 8866):

"For audio streams, encoding-params indicates the number of audio
channels. This parameter is OPTIONAL and may be omitted if the number
of channels is one, provided that no additional parameters
are needed."

This means that the number of channels is 1, if not specified within
rtpmap. It does not state that the codec's default value shall be used,
nor static payload definition.


Addionally the encoder always defines the number of channel. As the
encoding-params MAY be omitted, they are added to the rtpmap line, even
if the number of channels is 1.
After reading specs and having long conversation with Chat-GPT, I came up with a fix that should work with Asterisk now. The fix is pushed to libosmo-cc. SDP: Fix interpretation of number of channels within rtpmap The standard says (RFC 4566 / 8866): "For audio streams, encoding-params indicates the number of audio channels. This parameter is OPTIONAL and may be omitted if the number of channels is one, provided that no additional parameters are needed." This means that the number of channels is 1, if not specified within rtpmap. It does not state that the codec's default value shall be used, nor static payload definition. Addionally the encoder always defines the number of channel. As the encoding-params MAY be omitted, they are added to the rtpmap line, even if the number of channels is 1.
👍 1
jolly closed this issue 2024-04-22 18:47:02 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
jolly
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cellular-infrastructure/osmocom-analog#21
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?