- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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Å
- Tags:
- HTML5
- JavaScript*
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Anyone can help?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Seems your video SDP didn't passed the info check, can you please send us your SIP device SDP info?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The size of Woogeen.framework significantly increased after adding LLVM bitcode support. This is expected.
![](/skins/images/D3C0B914909A6564BBB97F4AD1ED1973/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page