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

[Peter Turczak (JIRA)]

Peter Turczak created ASTERISK-28832:
----------------------------------------

             Summary: 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)