I'm using jain-sip as standalone application. Everything works fine for my purposes.
I need to do some modification to my application - play audio file before terminating a call (something like PLAY_ANNOUNCEMENT).
It would be something like this:
-->INVITE
<-- 200 OK
<-- Play Audio
<-- Terminate call with BYE or CANCEL (depends on dialog state).
Currently it works without "Play Audio" step.
So my question is: How to use RestComm RTP stack separately from the RestComm MedaiServer?
Some update.
After studying MediaServer sources found that there must be RtpFactory class:
class="org.mobicents.media.server.impl.rtp.RtpFactory"
Found here rtp-beans.xml
But I can't find this class in the sources - RTP source
Any help?
Related
C++, WinRT, VS2017 MFC, Win10
I have a C++/WinRT VS2017 console app as a test platform to find my Bluetooth LE device, enumerate the services and characteristics, and then write a value to the Tx characteristic, etc. I have all of that working and now I am trying to move that code to an existing VS2017 MFC app.
In the console app the BluetoothLEAdvertisementWatcher and callback to the watcher.Received() were done in the main.cpp. Once my BLE device was found, a separate function was called to create the device object from the deviceAddress and then enumerate the services and characteristics.
In the MFC app I created a separate function run in a separate thread to establish the watcher and attach the callback. That all works fine up to the point that it needs to GetGattServicesAsync(). In the console app the function OpenDevice() used to create the device object and get the services was done with a get() as in:
OpenDevice(deviceAddress).get();
The first thing OpenDevice() does is create the device object using
auto device = co_await BluetoothLEDevice::FromBluetoothAddressAsync(deviceAddress);
If the device object is created, then the next thing it did was get the Services with:
auto services = co_await device.GetGattServicesAsync();
Here is where my MFC code fails. In the function thread that creates the watcher and watcher.Received callback my MFC code does the same call to OpenDevice(). In OpenDevice the device object is indeed created but then the call to GetGattServicesAsync() will never finish so matter how long I wait. If I enter the GetGattServicesAsync() in Debug mode, however, then it works fine.
For testing I have also put the OpenDevice() code within the watcher thread but, again, it stalls on GetGattServicesAsync().
In this case, however, I cannot use the co_await but had to use
auto services = device.GetGattServicesAsync().get();
Regardless, the GetGattServicesAsync() never finished.
Any suggestions of what I need to do or what I am doing wrong?
Since running in Debug was working I was trying to solve why this was not working in Release mode. I was relying on my log file entries to track the progress after the fact. For the halibut I put in some Beeps() to let me hear the progress and I was hearing beeps but not seeing log entries after that GetGattServicesAsync(). Apparently what was happening is that, for what ever reason, the GetGattServicesAsync() was NULLing out the handle to my log file so no writes were taking place. I did a check for NULL after the GetGattServicesAsync() and, if it was, re-established the log file. All of a sudden my log file was showing the progress that I thought was not happening. Sometime I think it is just me...:-(
I try to access frames of RTCVideoRenderer without success, can you help me please ?
I noticed that there is a "didCaptureVideoFrame" method in RTCVideoCapturerDelegate, but not in RTCVideoViewDelegate.
I have never done objc, I added a method in RTCVideoViewDelegate to get frames (bellow "didChangeVideoSize"), but it do not get fired, I guess it do not work like that.
I am able to access frames from the remote using Android using the "onFrame" of VideoSink, I thought it would be that easy using ios.
PS: To add the method, I took the framework from the pod and put it in the project, because I noticed that when you modify a pod, changes do not apply.
Here is the line I added :
- (void)videoView:(id<RTCVideoRenderer>)videoView didRenderVideoFrame:(RTCVideoFrame *)frame;
I will now try to compile the library with the changes I want.
EDIT:
I am now compiling the library, I noticed the need to change several files to be able to access frames, it will not be done just by adding 10 lines.
Solved thanks to this : How to get frame data in AppRTC iOS app for video modifications?
I used this line instead (because names changed since) :
#property(atomic, strong) RTCVideoFrame* videoFrame;
I wanted a "onFrame" like VideoSink on Android, but it will be ok for now.
I have a website that recieves WEBRTC from my mobileApp very well.
A new C++ module that I develop that should send video using WEBRTC to the same website is not working and I failed to know why.
NOT WORKING FILES:
https://drive.google.com/open?id=1-6ZsfcQztexAspYWB4Nzvgf2e0-0C8vC
WORKING FILE:
https://drive.google.com/open?id=1bL_WOW6L1mGCXQC6HT6a14Sa58hOIcAh
kindly advise. I am stuck.
SOLVED AT LAST:
the issue mainly was due mDNS that is activated on chrome but gives "network unreachable" from my code.
the main problem was due to mDNS that chrome activates by default while webrtc need a lib called libnice v>0.1.14 which is the current stable release to resolve local addresses.
second peerConnectionFactory init:
I had to pass threads parameter. not this but also I had to init the network thread differently.
g_worker_thread = rtc::Thread::Create();
g_worker_thread->Start();
g_signaling_thread = rtc::Thread::Create();
g_signaling_thread->Start();
g_networking_thread = **rtc::Thread::CreateWithSocketServer();**
g_networking_thread->Start();
I am not sure what is the reason of the second point but maybe because I initiate webrtc from my main function in c and not through a thread.
Anyway I hope this helps someone... I was stuck for two weeks to solve it.
I'm having problem making a permanent calibration in my embedded solution. I'm developing a Qt-based app for a Embedded Linux environment with touch screen. For this last part, I use tslib (configured by previous developers).
In what comes to simply calibrate the touch screen, everything is fine: ts_calibrate runs and creates the pointercal file correctly. If after calling ts_calibrate I run my Qt app (or ts_test), I can notice that the calibration is successful.
The problem is that the calibration results only works for 1 opening of my app: I calibrate with ts_calibrate, run my app, close it and if I run my app again, the screen is one again non-calibrated.
Now obviously I don't want to have to call the calibration each time my app is closed and reopened. The question is: how to make the calibration results become permanent? (that is, till another calibration is made)
Extra info:
I did some research on the web and I found this SO thread telling about a way to handle this problem using QWSServer. At first I disliked this solution since it depends on the Qt framework to do the job (I was expecting a more general, "C++ solution" (or a call to a script, whatever)). But I implemented it and it worked - but only in a specific case, namely, if I calibrate, open my software, close it and reopen it, then the calibration is maintained. But the problem nevertheless persists if I shut down the hardware completely, turn it on and run my app without a call to ts_calibrate (reloading the Linux kernel in the process); so this show to be only a partial solution and, therefore, not acceptable.
Trying to find the source of the problem, I created a copy of the pointercal file just after calibration and another copy of it after shutting down and turning up my hardware (and confirming that the calibration was over) and I noticed that the file was changed in the middle despite no call to the ts_calibrate or similar app was made:
After calibration:
55438 118 -1920736 -543 -36058 34531168 65536 800 480
After hardware shutdown:
-55040 1280 2526720 -288 35040 -34398240 -62768
The terminal log for the linux boot (tftp; bootm command) don't mention pointercal or a relevant calibration process.
Edit
I recently learned that the pointercal file located inside /etc/ is changing between sections because that entire folder is made new when the hardware is restarted. So what is essentially happening is that Tslib is going after a file that is constantly reset to default each time the hardware is restarted, and what I need to do is to configure Tslib not to look there, but to a more secure folder (in my case, the SD Card). The new question now is: how to do that? I know I have to configure the tslib.sh file making the TSLIB_CALIBFILE variable point to the new location of pointerscal, but tslib.shis itself inside /etc/, being itself temporary.
You have to change TSLIB_CALIBFILE in the image loaded via tftp.
That should do it, since you just have to change that once.
Just trying my hands on FreeRTOS. Following are my setup -
Micro-controller - AT32UC3A0512
Board - EVK1105
Using FreeRTOS
Environment - AVR Studio 5 with ASF latest 2.3 framework
I just created a new project from Example project FreeRTOS. I am checking the USART currently.
When run the example project, I am able to transmit characters from my development board to PC through USART but when I type or input something on my PC usart terminal program(using Putty), I am not able to see anything. Can anybody suggest what may be wrong? Or do I need to change the code in the current example code to get input and display on my terminal program for USART?
Thanks...
Off the top of my head, I'm thinking:
Is your putty character ending set right? Like probably utf-8 to send to your MCU?
Is your MCU receiving anything in its receive buffer?
Hope it helps (:
I figured out my problem too. It seemed that the task had an stackoverflow.
It didn't freeze but went into an infinite loop in the applicationstackoverflowhook function.
Giving the task more stack solved the problem.
I got the problem solved. I removed the ISR based code. Just I initialized the gpio module and then initialized the rs_232 mode for usart , rest I used the existing USART.h and usart.c file API to send or receive data in a FreeRTOS task. That solved my problem...