[asterisk-bugs] [JIRA] (ASTERISK-28832) chan_mobile creates PCMA streams that make some VoIP clients crash or not render received audio

[Peter Turczak (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-28832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Turczak updated ASTERISK-28832:
-------------------------------------

    Description: 
When using above combination, various VoIP clients (at user B's side) behave erratically.

The problem occur to both calls from user A to user B and vice-versa. 

In both cases, audio from B gets to A flawlessly. Audio from B to A either is replaced by silence on B's end or crashes the client altogether.

Using wireshark at B's side, both audio streams played flawlessly. I saw that A->B packets contained only 48 byte payload per packet, while B-> A contained 160 byte payload/packet.

I built several test fixtures and found out that RTP data frames with payload length below approximatly 80 bytes will crash or make several clients go deaf.

Reading RFC 3551, section 4.2 states:
{quote} A receiver SHOULD accept packets representing between 0 and 200 ms of audio data.  (For framed audio encodings, a receiver SHOULD accept packets with a number of frames  equal to 200 ms divided by the frame duration, rounded up.)  This restriction allows reasonable buffer sizing for the receiver.
{quote}

So this is basically a client issue, but all clients available to me are affected. To try out my theory, I built a patch for asterisk to use a smoother to repacketize the incoming stream from the BT device to the channel frame size.

I'd like to contribute my patch if there is interest in it.

  was:
When using above combination, various VoIP clients (at user B's side) behave erratically.

The problem occur to both calls from user A to user B and vice-versa. 

In both cases, audio from B gets to A flawlessly. Audio from B to A either is replaced by silence on B's end or crashes the client altogether.

Using wireshark at B's side, both audio streams played flawlessly. I saw that A->B packets contained only 48 byte payload per packet, while B-> A contained 160 byte payload/packet.

I built several test fixtures and found out that RTP data frames with payload length below approximatly 80 bytes will crash or make several clients go deaf.

Reading RFC 3551, section 4.2 states:
{quote} A receiver SHOULD accept packets
   representing between 0 and 200 ms of audio data.  (For framed audio
   encodings, a receiver SHOULD accept packets with a number of frames
   equal to 200 ms divided by the frame duration, rounded up.)  This
   restriction allows reasonable buffer sizing for the receiver.
{quote}

So this is basically a client issue, but all clients available to me are affected. To try out my theory, I built a patch for asterisk to use a smoother to repacketize the incoming stream from the BT device to the channel frame size.

I'd like to contribute my patch if there is interest in it.


> chan_mobile creates PCMA streams that make some VoIP clients crash or not render received audio
> -----------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-28832
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28832
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Addons/chan_mobile
>    Affects Versions: 16.2.1
>         Environment: Tested and debugged on debian stretch on arm hardware (RPi 3).
> VoIP clients:
> - Gigaset VoIP N510 Pro (no audio)
> - Yeahlink SIP-T54W (no audio)
> - Linux VoIP client (crashes, not yet disclosed)
> BT Hardware:
> - iPhone XS
> - iPad Mini 3
> - Samsung Galaxy  GT-S7582
> Logical setup:
> User A <-> Mobile Network <-> BT-Hardware <-> chan_mobile <-> asterisk <-> pjsip <-> VoIP Client <-> User B
>            Reporter: Peter Turczak
>
> When using above combination, various VoIP clients (at user B's side) behave erratically.
> The problem occur to both calls from user A to user B and vice-versa. 
> In both cases, audio from B gets to A flawlessly. Audio from B to A either is replaced by silence on B's end or crashes the client altogether.
> Using wireshark at B's side, both audio streams played flawlessly. I saw that A->B packets contained only 48 byte payload per packet, while B-> A contained 160 byte payload/packet.
> I built several test fixtures and found out that RTP data frames with payload length below approximatly 80 bytes will crash or make several clients go deaf.
> Reading RFC 3551, section 4.2 states:
> {quote} A receiver SHOULD accept packets representing between 0 and 200 ms of audio data.  (For framed audio encodings, a receiver SHOULD accept packets with a number of frames  equal to 200 ms divided by the frame duration, rounded up.)  This restriction allows reasonable buffer sizing for the receiver.
> {quote}
> So this is basically a client issue, but all clients available to me are affected. To try out my theory, I built a patch for asterisk to use a smoother to repacketize the incoming stream from the BT device to the channel frame size.
> I'd like to contribute my patch if there is interest in it.



--
This message was sent by Atlassian JIRA
(v6.2#6252)