Add new clearmode codec support for data calls

Manawyrm commented

2023-03-05 18:36:11 +00:00

Owner

This new codec will get handled like RFC4040 in yrtpchan, ysipchan
and will just be handled as alaw audio in zapcard/DAHDI.

The zapcard code will set the udi bearer cap to any calls with the
clearmode format (which would get sent via SIP/SDP).

~~The rtpmap ID (106 in this case) is a bit of a mystery.~~
~~Fritz!Box routers seem to send 106, Zyxel seems to send 96 and the RFC mentions 97.~~

This new codec will get handled like RFC4040 in yrtpchan, ysipchan and will just be handled as alaw audio in zapcard/DAHDI. The zapcard code will set the udi bearer cap to any calls with the clearmode format (which would get sent via SIP/SDP). ~~The rtpmap ID (106 in this case) is a bit of a mystery.~~ ~~Fritz!Box routers seem to send 106, Zyxel seems to send 96 and the RFC mentions 97.~~

laforge commented

2023-03-05 19:12:47 +00:00

Owner

The RTP RFC defines some ranges of payload ID as static, and some for dynamica allocation.

The point of rtp-mapping is to dynamically allocate RTP payload types with codec names.

So the "a=rtpmap:97 CLEARMODE/8000" example from the RFC4040 text basically instructs the recipient of that SDP snippet that the payload format CLEARMODE/8000 is transmitted as RTP payload type 97.

So you can not really make any assumption about the payload type. Every call can use a different RTP PT, as stated in the associated SDP.

The RTP RFC defines some ranges of payload ID as static, and some for dynamica allocation. The point of rtp-mapping is to dynamically allocate RTP payload types with codec names. So the "a=rtpmap:97 CLEARMODE/8000" example from the RFC4040 text basically instructs the recipient of that SDP snippet that the payload format CLEARMODE/8000 is transmitted as RTP payload type 97. So you can not really make any assumption about the payload type. Every call can use a different RTP PT, as stated in the associated SDP.

laforge commented

2023-09-07 08:45:16 +00:00

Owner

Just saw this PR again. I have little knowledge about yate internals. Did you have a chance to compare the code / your patch against my statements regarding how dynamic RTP port mapping with SDP works?

Manawyrm force-pushed manawyrm-clearmode from c76fd0b6b6 to 79aea14938

2023-09-19 15:51:59 +00:00

Compare

Manawyrm commented

2023-09-19 15:56:32 +00:00

Poster

Owner

Just saw this PR again. I have little knowledge about yate internals. Did you have a chance to compare the code / your patch against my statements regarding how dynamic RTP port mapping with SDP works?

Yup, they were very helpful and now I've also had time to update this patch properly. I've uploaded a version 2 of the commit.

Turns out:
The rtmap ID in the yate source code is just what yate will request on an outgoing call.
On inbound calls, Yate will accept any rtp mappings with the "CLEARMODE/8080" string and create an appropriate mapping for them.

I've set the rtmap ID to 97 now (as mentioned in the RFC4040 example, and also because Yate wasn't using it yet).
The code still works against the FritzBox (which then requests rtpmap 106), which the yate will then handle properly:

  'media' = 'yes' (NamedString)
  'formats' = 'clearmode' (NamedString)
  'transport' = 'RTP/AVP' (NamedString)
  'rtp_mapping' = 'clearmode=106' (NamedString)
  'rtp_rfc2833' = 'false' (NamedString)

> Just saw this PR again. I have little knowledge about yate internals. Did you have a chance to compare the code / your patch against my statements regarding how dynamic RTP port mapping with SDP works? Yup, they were very helpful and now I've also had time to update this patch properly. I've uploaded a version 2 of the commit. Turns out: The rtmap ID in the yate source code is just what yate will request on an outgoing call. On inbound calls, Yate will accept any rtp mappings with the "CLEARMODE/8080" string and create an appropriate mapping for them. I've set the rtmap ID to 97 now (as mentioned in the RFC4040 example, and also because Yate wasn't using it yet). The code still works against the FritzBox (which then requests rtpmap 106), which the yate will then handle properly: ``` 'media' = 'yes' (NamedString) 'formats' = 'clearmode' (NamedString) 'transport' = 'RTP/AVP' (NamedString) 'rtp_mapping' = 'clearmode=106' (NamedString) 'rtp_rfc2833' = 'false' (NamedString) ```

laforge commented

2023-09-19 16:20:10 +00:00

Owner

thanks a lot for your work. I originally assumed that payload types > 127 are dynamic, but re-reading the spec taught me that the whoe PT field is 7 bit only and 96..127 are reserved for dynamic mappings. Therefore, using 97 for CLEARMODE is perfectly fine.

laforge merged commit 79aea14938 into master

2023-09-19 16:20:18 +00:00

laforge deleted branch manawyrm-clearmode

2023-09-19 16:20:18 +00:00

laforge referenced this issue from a commit

2023-10-03 09:17:05 +00:00

Directory reorder #2

Add new clearmode codec support for data calls #2