A can call B -> video works fine
B can call A -> there is only Audio, cannot add h264 video.
So both device have video capabilities, and one way it works fine there is no reason why it shouldnt be in the other way around.
I get back the following from the bria support: Asterisk server is only sending m=video line but not the rtpmap and fmtp lines which Bria will be looking for and the video doesn’t go through
As well have you enabled videosupport in the general section? From sip.conf.sample:
;videosupport=yes ; Turn on support for SIP video. You need to turn this
; on in this section to get any video support at all.
; You can turn it off on a per peer basis if the general
; video support is enabled, but you can't enable it for
; one peer only without enabling in the general section.
; If you set videosupport to "always", then RTP ports will
; always be set up for video, even on clients that don't
; support it. This assists callfile-derived calls and
; certain transferred calls to use always use video when
; available. [yes|NO|always]
To be honest, I found something which might be the solution but no way on earth I gonna reenable that nightmare pjsip since it brings a hell of a lot issues starting with the cisco authentication was not working properly etc.
exten => 208,1,Set(codec=h264) ;manually set variable
exten => 208,n,Set(PJSIP_MEDIA_OFFER(video)=!all,${codec}) ;set invite with defined variable
exten => 208,n,Set(PJSIP_SEND_SESSION_REFRESH()=invite) ;send invite with variable
exten => 208,n,Dial(PJSIP/208, 30)
So this code suppose to set the inband codec to h264 when the extension is called but as I said I had so many problem with pjsip I never even got this far, I wonder if this is doable with the regulr SIP.
Cisco doesn’t adhere to the RFC like other devices and as a result the force_rport option must be set to “no” for them or else SIP responses will not go to the correct location. This also applies to chan_sip, although the option is named differently there.
The chan_sip module has its own variables which can be used to control codecs some.
That probably explains why we never had problems with Cisco. There is urban folklore out there that says that every chan_sip configuration must have nat=yes, which, in recent years, became every one should have nat=force_rport, comedia, as that was deemed equivalent.
I think the the first thing to do is to go through sip.conf.sample and create the configuration from first principles, rather than cutting and pasting configurations that are designed to put the fewest obstacles in the way of working first time with ITSPs (at the expense of, for example, security).
As I noticed it’s not possible to completely disable audio codecs, I have tried to only leave h264 in for the 2 peers and Asterisk just disconnects with error.
[Jan 18 19:31:41] NOTICE[-1][C-00000000]: chan_sip.c:7371 try_suggested_sip_codec: Ignoring ${SIP_CODEC*} variable because it is not shared by both ends: h264
[Jan 18 19:31:41] NOTICE[-1][C-00000000]: chan_sip.c:7371 try_suggested_sip_codec: Ignoring ${SIP_CODEC*} variable because it is not shared by both ends: h264
I have modified the extension for both phones to be the same and their sip.conf section is the same as ell so I don’t know why does it say not shared by both ends.
I have tried g722&h264 and h264 only as well. In this last case when there is h264 only the audio call was established but when I choose add video from bria it just dropped the connection, so yeah this does change something at least on the behaviour.
