Intel® Collaboration Suite for WebRTC
Community support and discussions on the Intel® Collaboration Suite for WebRTC (Intel® CS for WebRTC).

No video with SIP

Vincent_R_1
Beginner
990 Views

Hi

Installed CS version 3.4 on azure.

When i join from webRTC, audio and video works well.

When i tried to join from a SIP device, connections are audio only.  SIP log below.  Is it a config issue somewhere?  I used the sip2sip.info service for this test, could that be the issue too?

Thanks for the help

-VR

-SIP LOG

2017-08-12 17:17:46.567  - INFO: ErizoJS - Connecting to rabbitMQ server...
2017-08-12 17:17:46.588  - INFO: AmqpClient - Connecting to rabbitMQ server OK, hostPort: { host: 'localhost', port: 5672 }
Local network address:  IPv4=eth0:10.0.0.9 
aucodec: PCMU/8000/1
aucodec: opus/48000/2
vidcodec: H265
vidcodec: H264
vidcodec: H264
vidcodec: VP8
sipua is ready.
2017-08-12 17:17:46.609  - INFO: ErizoJS - sip.c4196b83-1853-7073-0a72-58fe09c8d000.1 as rpc server ready
2017-08-12 17:17:46.612  - INFO: ErizoJS - sip.c4196b83-1853-7073-0a72-58fe09c8d000.1 as monitor ready
2017-08-12 17:17:51,020  - DEBUG: sip.SipGateway - SipGateway constructor
2017-08-12 17:17:51,021  - DEBUG: sip.SipEP - SipEP()
2017-08-12 17:17:51,021  - DEBUG: sip.SipGateway - setEventRegistry - add listener 0x2f84278
2017-08-12 17:17:51,021  - WARN: sip.SipEP - !!Create sipua OK!

sipalias_mcu@sip2sip.info: {0/UDP/v4} 200 OK (SIP Thor on OpenSIPS XS 1.11) [2 bindings]
2017-08-12 17:17:52,460  - DEBUG: sip.SipEP - Register OK
2017-08-12 17:17:52,460  - DEBUG: sip.SipGateway - notifyAsyncEvent - event: SIPRegisterOK
sip:sipalias_endpoint@sip2sip.info:5060: call_accept
sipalias_mcu@sip2sip.info: Call incomming: sip:sipalias_endpoint@sip2sip.info:5060 owner ep 0x2f84920
2017-08-12 17:18:19,714  - DEBUG: sip.SipEP - An incomming call from sip:sipalias_endpoint@sip2sip.info:5060
2017-08-12 17:18:19,714  - DEBUG: sip.SipGateway - notifyAsyncEvent - event: IncomingCall
2017-08-12 17:18:19,729  - DEBUG: sip.SipEP - Web accepted
2017-08-12 17:18:19,729  - DEBUG: sip.SipGateway - insertCallInfoByPeerURI sip:sipalias_endpoint@sip2sip.info:5060
answering call from sip:sipalias_endpoint@sip2sip.info:5060 with 200
audio: Set audio decoder: PCMU 8000Hz 1ch
audio: Set audio encoder: PCMU 8000Hz 1ch
2017-08-12 17:18:19,729  - DEBUG: sip.SipGateway - onSipAudioFmt:sip:sipalias_endpoint@sip2sip.info:5060-PCMU-8000
2017-08-12 17:18:19,729  - DEBUG: sip.SipGateway - insertOrUpdateCallInfoByPeerURI sip:sipalias_endpoint@sip2sip.info:5060
video stream is disabled..
call: video stream is disabled..
sipalias_mcu@sip2sip.info: Call established: sip:sipalias_endpoint@sip2sip.info:5060
2017-08-12 17:18:19,993  - DEBUG: sip.SipEP - Call established
2017-08-12 17:18:19,993  - DEBUG: sip.SipGateway - insertOrUpdateCallInfoByPeerURI sip:sipalias_endpoint@sip2sip.info:5060
2017-08-12 17:18:19,993  - DEBUG: sip.SipGateway - notifyAsyncEvent - event: CallEstablished
2017-08-12 17:18:19,993  - DEBUG: sip.SipGateway - refreshVideoStream
2017-08-12 17:18:19,994  - DEBUG: sip.SipCallConnection - SipCallConnection() Codec info PCMU 
sipsess_info_handler: msg->ctype = sÅ

 

0 Kudos
7 Replies
Vincent_R_1
Beginner
990 Views

Anyone can help?

0 Kudos
Lei_Z_Intel1
Employee
990 Views

Seems your video SDP didn't passed the info check, can you please send us your SIP device SDP info?

0 Kudos
Lei_Z_Intel1
Employee
990 Views

Hi, VR

Based on your log, that did caused by the difference between v3.3 and v3.4. In v3.4 we restrict the packetization-mode to 1 rather than both 0 and 1. In previous versions, mode 0 is not really supported although some of the client can interpret mode 1 package sent from MCU, like your device. So as workaround, can you please set your device to support the packetization-mode 1?

=====================================================================================

a=rtpmap:97 H264/90000

a=fmtp:97 profile-level-id=42801f;packetization-mode=0;max-br=10240;max-mbps=490000;max-fs=8160

0 Kudos
leo_a_
Beginner
990 Views

Lei Zhai (Intel) wrote:

Hi, VR

Based on your log, that did caused by the difference between v3.3 and v3.4. In v3.4 we restrict the packetization-mode to 1 rather than both 0 and 1. In previous versions, mode 0 is not really supported although some of the client can interpret mode 1 package sent from MCU, like your device. So as workaround, can you please set your device to support the packetization-mode 1?

=====================================================================================

a=rtpmap:97 H264/90000

a=fmtp:97 profile-level-id=42801f;packetization-mode=0;max-br=10240;max-mbps=490000;max-fs=8160

 

 

Hi, Lei Zhai,

       May I ask why the size of Woogeen.framework in IOS SDK is so large?

0 Kudos
Jianjun_Z_Intel
Employee
990 Views

Hi leo,

The Woogeen.framework has a static library which support three architectures: armv7, arm64 for iOS devices and x86_64 for iOS simulators. It also contains bitcode. That's why the framework is so large. However, the app you delivery to end users will be stripped. It will be much smaller.

0 Kudos
leo_a_
Beginner
990 Views

Jianjun Z. (Intel) wrote:

Hi leo,

The Woogeen.framework has a static library which support three architectures: armv7, arm64 for iOS devices and x86_64 for iOS simulators. It also contains bitcode. That's why the framework is so large. However, the app you delivery to end users will be stripped. It will be much smaller.

 

I know it contains armv7, arm64 and x86_64, but the Woogeen.framework below version 3.2 just less than 70M. I try to get arm64 only from Woogeen.framework in version 3.4, but it still take more than 400M size.

0 Kudos
Jianjun_Z_Intel
Employee
990 Views

The size of Woogeen.framework significantly increased after adding LLVM bitcode support. This is expected.

0 Kudos
Reply