Як зробити обробку вхідного виклику для Android-застосунку (softphone)

Усі статті, обговорення, новини про Mobile — в одному місці. Підписуйтеся на телеграм-канал!

Всім привіт!

Знайшов проєкт на GitHub. SIP softphone для підключення до серверу Asterisk, який працює через wss сокет та використовує webrtc, також може використовувати відеокодек H264.

Після створення APK та підключення до сервера, все працює нормально — і відео, і аудіо, все норм. Але вхідний виклик успішний тільки тоді, коли у вхідному відеовиклику в SDP-пакеті надсилається параметр кодека H264 — packetization-mode=1. Якщо використовується якийсь інший SIP агент і цього параметра немає, або packetization-mode=0, дзвінок негайно закривається (SIP/2.0 488 Not Acceptable Here).

Підкажіть, будь ласка, хто знає, куди тут дивитись, чи в сторону webrtc, чи в самому застосунку десь має бути обробка вхідного виклику саме так і не інакше (бо зазвичай SIP-агенти обробляють всі основні варіанти параметрів цього кодека). Оскільки це flutter, то там можна створити застосунок під Chrome — і там все працює нормально з будь-яким параметром packetization-mode, а от для Android — тільки packetization-mode=1.

Дякую.

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую за відповідь.
Сам проект написаний на flutter (dart). Тому є можливість створювати застосунок і під Google Chrome і під ANDROID і під IOS. Під Chrome все працює чудово з вхідними відеовикликами з будь яким параметром packetization-mode і навіть зовсім без нього.
Я саме і використовую Linphone, тому що в цьому застосунку і в десктопній версії і в андроід версії є можливість в налаштуваннях відео вписати різні параметри кодека H264. Потім ці параметри можно прослідити в SDP пакетах, які надходять до застосунку. Таким чином я знайшов причину, чому деякі SIP агенти при відеовиклику працюють нормально а деякі не працюють зовсім. Перебрав декілька параметрів типу profile-level-id, level-asymmetry-allowed і виявив що лише з параметром packetization-mode=1 цей застосунок коректно обробляє вхідний відеовиклик і все працює нормально, є і відео і аудіо.
Якщо я правильно розумію, логічно було б, якщо б застосунок обробляв хоча б декілька базових параметрів — наприклад
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=fmtp:104 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
Тому, напевно, треба копатись в самому вихідному коді застосунка і шукати де саме обробляється вхідний виклик і що саме очікується, які параметри.

Я так розумію, що проблема у вас виникає, коли ви обробку H264 передаєте на системну бібліотеку в самому девайсі. Тобто реалізація кодека у вас зроблена на рівні системи, а не вбудованою в софтфон (SDK) бібліотекою. Що абсолютно ок.
Тому тут треба дивитись на вимоги конкретно девайса. Якщо що, робити хаки під конкретних виробників знаючи про такі моменти — абсолютно ок.
Як варіант — протестувати пристрої іншого виробника. Також варіант — подивитись на інші реалізації, як приклад — gitlab.linphone.org/...​C/public/linphone-android

Підписатись на коментарі