Videocall to Android app (Flutter)

[John]

Hello
I use the SIP app from github.
This application is written in flutter + dart and use sip over websocket, audio/video calls (flutter-webrtc) and instant messaging.
Using this application on Android, I discovered a problem with video when using the H264 codec only.
When another SIP agent (Linphone, Microsip, Xlite) videocalls to application with a codec parameter packetization-mode=1 - everything works fine, both audio and video.
for example, a piece of SDP

m=video 49452 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1

But if this parameter (packetization-mode) is missing or packetization-mode=0 - the call immediately disconnects with massage:

SIP/2.0 488 Not Acceptable Here

For tests I used Linphone since you can specify codec parameters there.

Please tell me, if there could be a problem in the asterisk settings, or problem may be in the application?

P.S. When I call from app to any SIP agent - everything works fine

[Chano]

Are all calls performed through the same Asterisk server? Some apps, especially on mobile, perform the call through their own servers before sending them to your server, which could cause issues as well.

You also need to make sure the h264 codec is allowed on ALL channels/endpoints involved in the call, and the h264 related Asterisk modules are loaded.

Also try looking at the SIP traffic, the “Not acceptable here” could come from the receiving endpoint, instead of Asterisk, as Asterisk is not capable of transcoding video.

[John]

Thanks for your reply
Yes all calls performed through my own Asterisk server.
All SIP agents are registered on the Asterisk server directly.
Between all SIP agents, like Microsip or Linphone - all calls are successful.
The problem is only with this Android application.
I create APK from source github code and since this is flutter, I can create app for Google Chrome or Windows or IOS.
After creation, i must input
websocket address like
wss://my server ip:8089/ws

SIP URI like
9004@my server ip

Auth user like
9004

auth pass like
9004

and register on the server. I can see the registration in the server logs, all right. And after that I call from Linphone to Google Chrome app with packetization-mode=0 or packetization-mode=1 or without this parameter at all, no matter - everything OK - audio/video OK.

But, after creation this same app on Android, and doing the same steps as above, everything OK only when parameter packetization-mode=1.
If some SIP agent doesn’t have this parameter or packetization-mode=0 ( Like my intercom, for example, which can be connected to an asterisk and which use`s a pure codec H264 without any parameters and cannot be changed)
(piece of SDP packet from my Intercom)
a=rtpmap:99 H264/90000
a=rtcp-mux
a=sendrecv

In this case - call is dropped immediately.

I need to understand where the problem could be, in the Asterisk server or in the application itself

My sip.conf

[general]
disallow=all
allow=alaw,ulaw,h264

externip=my external IP
udpbindaddr=0.0.0.0:5092

srvlookup=no
mohsuggest=default
parkinglot=default
allowguest=no
alwaysauthreject=yes
videosupport=yes
ignoreregexpire=no
allowsubscribe=yes
notifyringing=yes
callcounter=yes
rtptimeout=120
rtpkeepalive=60
jbenable=yes
jbforce=no
jbmaxsize=200
jbresyncthreshold=1000
jbimpl=fixed
jblog=no
websocket_enabled=yes

[basic] (!)
type=friend
qualify=yes
context=from-extensions
subscribecontext=subscriptions
host=dynamic
directmedia=no
nat=force_rport,comedia
dtmfmode=rfc2833
disallow=all
videosupport=yes

[phones] (!)
transport=udp
allow=alaw,ulaw,h264

[webrtc] (!)
transport=wss
allow=alaw,ulaw,h264
encryption=yes
avpf=yes
force_avp=yes
icesupport=yes
rtcp_mux=yes
dtlsenable=yes
dtlsverify=fingerprint
dtlscertfile=/etc/asterisk/keys/asterisk.pem
dtlscafile=/etc/asterisk/keys/ca.crt
dtlssetup=actpass

[ 8002 ] (basic,phones)
callerid=“8002” <8002>
secret=888888

[ 9004 ] (basic,webrtc)
callerid=“9004” <9004>
secret=9004

[Chano]

Codec selection is something the SIP endpoints will do, they negotiate with a common codec from the SDP message. If no common codec is found, call will be rejected. For most Audio combinations, Asterisk is able to transcode the stream, by letting Asterisk transcode it can transcode between eg. g722 and PCM-A.

For video, Asterisk does NOT provide transcoding, and as such all endpoints MUST support the same codes, with compatible parameters. There’s NOTHING that can be done on the Asterisk side of things, to fix this.

[John]

Thank you
I understand - I will look at the application itself