add support for dtmf rtp events into rtpdump

[tsearle]

No description provided.

[mcd500]

Hi @tsearle,

Thank your for creating pull request.
Do you mind elaborating your intention of adding dynamic payload id as the argument on rtpdump?

The rtpdump is for outputting parsed text format file or binary file from the listing network or a file.
So it is not made to add additional content to the output file from the argument of rtpdump.
It only meant to write the content of network data of a file to the output file.

And the patches only adding output for pt=10 and pt=11 which are L16 while there are many different Payload types.

Please refer the test format of the output file at the rtpdump section at the bellow link.
https://www.cs.columbia.edu/irt/software/rtptools/

[tsearle]

The goal of the patch is to be able to understand dtmf. As rtp events are a dynamic payload type. You need to specify which payload id is used for that. We use rtpdump in the context of automated testing where we evaluate ssrc, sequence numbers, and timestamps for correctness, including for dtmf where there are special rules for it Torrey

…

On Thu, 17 May 2018, 16:27 Akira Tsukamoto, ***@***.***> wrote: Hi @tsearle <https://github.com/tsearle>, Thank your for creating pull request. Do you mind elaborating your intention of adding dynamic payload id as the argument on rtpdump? The rtpdump is for outputting parsed text format file or binary file from the listing network or a file. So it is not made to add additional content to the output file from the argument of rtpdump. It only meant to write the content of network data of a file to the output file. And the patches only adding output for pt=10 and pt=11 which are L16 while there are many different Payload types. Please refer the test format of the output file at the rtpdump section at the bellow link. https://www.cs.columbia.edu/irt/software/rtptools/ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#110 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEVHozStDsTD7EE1jm9o3GA2VG8eBokaks5tzYjmgaJpZM4UBdbG> .

[mcd500]

Hi @tsearle,

Thanks for the explanation.
Are you evaluation dtmf in the RFC2833 in your automated testing?
How are you using the command option on rtpdump with your patches?

The output file from rtpdump must be acceptable as input file of rtpplay and rtpsend.
Is there a good way to keep the compatibility with them?

[tsearle]

We invoke rtpdump from sipp scripts. The. We analyse the output for rfc compliance via perl scripts. We integrate this inside the asterisk testsuite. If I understand correctly rtpplay needs to be modified to be able to re-encode the dtmf information or does it need to simply discard it? Torrey

…

On Sun, 20 May 2018, 12:46 Akira Tsukamoto, ***@***.***> wrote: Hi @tsearle <https://github.com/tsearle>, Thanks for the explanation. Are you evaluation dtmf in the RFC2833 in your automated testing? How are you using the command option on rtpdump with your patches? The output file from rtpdump must be acceptable as input file of rtpplay and rtpsend. Is there a good way to keep the compatibility with them? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#110 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEVHo4Se9ElpeO5dQVy-gIu1p-ySpliWks5t0UmhgaJpZM4UBdbG> .

[mcd500]

I have not tested by myself, from reading the source code of rtpdump with the patches and rtpsend, it probably needs deleting the lines which was added by the patches to use as a input file for rtpsend.

[tsearle]

I just checked and rtpsend works ok without any modification, the change in the format of rtp dump only adds additional key-value pairs to some lines. These key/value pairs turned into a linked list in rtp send, where it consumes the keys it knows about & ignores the ones it doesn't Example output from rtp dump 1526356809.449984 RTP len=32 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=18 (G729,1,8000) seq=10200 ts=29440 ssrc=0x52e7e60d 1526356809.470124 RTP len=32 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=18 (G729,1,8000) seq=10201 ts=29600 ssrc=0x52e7e60d 1526356809.490067 RTP len=32 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=18 (G729,1,8000) seq=10202 ts=29760 ssrc=0x52e7e60d 1526356809.509943 RTP len=32 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=18 (G729,1,8000) seq=10203 ts=29920 ssrc=0x52e7e60d 1526356809.530084 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=1 pt=101 (????,0,0) seq=10204 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=20ms end=0 1526356809.530100 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10205 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=20ms end=0 1526356809.788958 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10206 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=20ms end=0 1526356809.809131 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10207 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=40ms end=0 1526356809.829149 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10208 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=60ms end=0 1526356809.849029 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10209 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=80ms end=0 1526356809.869065 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10210 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=100ms end=0 1526356809.889125 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10211 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=120ms end=0 1526356809.908963 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10212 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=140ms end=0 1526356809.928968 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10213 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=160ms end=0 1526356809.949055 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10214 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=180ms end=0 1526356809.969000 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10215 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=200ms end=0 1526356809.988991 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10216 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=220ms end=0 1526356810.008942 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10217 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=240ms end=0 1526356810.028944 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10218 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=260ms end=0 1526356810.029063 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10219 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=280ms end=0 1526356812.090320 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10220 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=2560ms end=1 1526356812.090340 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10221 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=2560ms end=1 1526356812.090344 RTP len=16 from=127.0.0.1:18802 v=2 p=0 x=0 cc=0 m=0 pt=101 (????,0,0) seq=10222 ts=30240 ssrc=0x52e7e60d dtmf=1 duration=2560ms end=1 rtpsend can play this file without generating any errors, the extra keys dtmf, duration, and end are ignored Torrey

…

On 22 May 2018 at 05:31, Akira Tsukamoto ***@***.***> wrote: I have not tested by myself, from reading the source code of rtpdump with the patches and rtpsend, it probably needs deleting the lines which was added by the patches to use as a input file for rtpsend. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#110 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEVHo25x9J5ha7TE9bJa-7iUsH4zIw2xks5t04ahgaJpZM4UBdbG> .

[mcd500]

Thank you for trying the saved file from rtpdump with your patch as the input file on rtpsend.
To include your patches, the people, who is going to use rtpdump with you patches, would greatly appreciate how to use the added new dtmf option, for example, the usage of your testing.
Would you mind replying my question earlier on this?
I am not the expert on dtmf packets, and it does not seem to have the value for the following parameters in the header. What should be stored on these parameters?
pt_map[r->pt].enc, pt_map[r->pt].ch, pt_map[r->pt].rate

[tsearle]

In SDP it is identified telephone-event, so that's a value that can be used for "enc", channels ch can be 1 as it can be considered a highly compressed form of audio. However rate is complicated. Generally 8000 is used, but it can be dynamic based on sdp (if you are doing DTMF in an hd voice call, then you would have a sample rate matching that) So it's probably best to leave sample rate as unkown Regards, Torrey

…

On 27 May 2018 at 15:13, Akira Tsukamoto ***@***.***> wrote: Thank you for trying the saved file from rtpdump with your patch as the input file on rtpsend. To include your patches, the people, who is going to use rtpdump with you patches, would greatly appreciate how to use the added new dtmf option, for example, the usage of your testing. Would you mind replying my question earlier on this? I am not the expert on dtmf packets, and it does not seem to have the value for the following parameters in the header. What should be stored on these parameters? pt_map[r->pt].enc, pt_map[r->pt].ch, pt_map[r->pt].rate — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#110 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEVHo3c9hseyBHJCyKXPKyQCgNlir605ks5t2qZngaJpZM4UBdbG> .