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

[George Joseph (JIRA)]

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

George Joseph updated ASTERISK-28832:
-------------------------------------

    Status: Open  (was: Triage)

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