I have a file on AWS S3 that is public:
https://s3-eu-west-1.amazonaws.com/voxist-greetings/33631222504/33651291239_95113eed-386b-4264-a4cf-46182faae125COUCOU1.wav
Now when RVD try to play it I get:
INFO [org.mobicents.servlet.restcomm.interpreter.VoiceInterpreter] (RestComm-akka.actor.default-dispatcher-8586) MediaGroupResponse, succeeded: false jain.protocol.ip.mgcp.JainIPMgcpException: The IVR request failed with the following error code 312
I don't know why... The same file used to work with another name.
Thanks for any hint on how to debug this.
The problem seems to happen on Media Server side. More specifically, it seems the file cannot be opened for some reason.
Relevant code line can be found here.
Can you please take a tcpdump and share it, so we can see the MGCP Play request?
Hope this helps.
UPDATE:
Here is an example:
The 200 OK simply indicates that the MGCP transaction completed successfully. Now we need to dissect the notification (NTFY) sent from Media Server to RestComm, mainly the ObservedEvents parameter.
If you look at the picture, you will see the event triggered is an OperationFailed (of) with ReturnCode (rc) equal to 312, which is an error.
Relevant link to specs can be found here.
To summarise, Media Server receives the request to play the file (in this case a cached version of it) but if fails to open the URL for some reason.
Is the URL reachable from Media Server side?
Related
With some Uploads in Moodle (3.9) Uploads are not successful, mainly pdf.
The message that comes up is: "An error occured whilst communicating with the server".
not successful requests show
POST /course/dndupload.php undefined
successful requests show
POST /course/dndupload.php HTTP/1.1
When a pdf is reexported with libre office for example the same pdf can be uploaded without problems.
any ideas?
Is the LibreOffice pdf smaller? It could be PHP timing out.
https://docs.moodle.org/311/en/File_upload_size#Modifying_the_php.ini_file
What is the value for max_execution_time ? You can check the PHP values here -
Site administration > Server > PHP info
Also, try switching debug to developer level and see what the error message is.
Site administration > Development > Debugging
Debug messages = Developer
Display debug messages = checked
Although be cautious changing the debug level if its a production site. If you have access to the config.php file then you can specify a user.
// You can specify a comma separated list of user ids that that always see
// debug messages, this overrides the debug flag in $CFG->debug and $CFG->debugdisplay
// for these users only.
// $CFG->debugusers = '2';
Thanks for the response, in the meantime a solution to the problem was found. On the server a measurement against log4j2-vulnerability has been implemented: https://support.f5.com/csp/article/K59329043#proc2. This caused the misbehaviour, the iRule has been removed, now it works again.
I’m trying to get a mod_perl2 application ported to AWS. As part of the port I thought I’d move from Debian Squeeze to Wheezy with the latest stable mod_perl & Apache2 combination.
The application works right up to the point I try and write JSON responses to the client. At this point, each request is canceled on the client and on the server I get the error
Apache2::RequestIO::print: (103) Software caused connection abort
whenever I write to the client, i.e.:
$self->req->print($output);
I’ve tried tcpdumping the response to the client, and I can see it being written out, but no response is received on the client end and it just barfs chips. I can’t find any information on how to get around this.
I found quite a few people asking about this question on the net without many answers. The solution to my problem was very specific but I thought I’d post what I did anyway, it may help someone.
The client was canceling the request before the response was fully written, which was crapping out Apache::RequestIO (for reasons I still don’t know).
I couldn’t work out why I was seeing this behavior.
By using tcpdump I could see that data was being written out to the client – and it looked fine.
By inspecting the page in Chrome and looking at the network stack, I could see that my request for data was being canceled after no response was received (which was odd because the code worked fine on other servers and I could see the response was being written). Debugging was may harder because with Apache crashing out with an error in print IO I couldn’t check if the bytes written equaled the bytes of data. I wasn’t sure if something was getting stuck on the server side.
So, I changed the Content-Type of the response from application/json to text/html, so that I could query the page and just look at the actual response as text. Once I did that, I could see that the response was fine.
I started to look for other causes, and I found that in the migration to the new server, I’d missed altering some URLs in the DB to point to the new server, which meant my application was trying to get some data from the old DB.
This in turn was causing a load of timing issues, which was causing my problems. Once I fixed the config, the problems went away.
I am using Windows Explorer to test the WebDAV implementation I am adapting to our system. The implementation is using IIS Express and is launched by Visual Studio 2013. I turned off Windows Explorer's requirement for SSL with WebDAV so I can test basic authentication (which works).
The problem I am having is with the Write method of the DavFile implementation. I connect to the web folder, navigate to a sub folder, then attempt to copy a JPG file from a folder on my computer's hard drive, into the WebDAV sub folder (using Windows Explorer).
The attempt to copy up a file (854kb) fails. When I set a break point, I notice that the "segment" stream (one of the input parameters on the "write" method, shows 0 (zero) bytes length.
Any tips on how to debug this problem? What is the most likely cause of 0 byte in the stream?
Here are some ideas about how to understand what is going wrong:
Examine the server log for exceptions. By default it is called WebDAVLog.txt and located in \App_Data\WebDAV\Logs\ folder. Are there any exceptions in it? Check your server log and make sure all requests were successful.
Examine WebDAV requests with a Fiddler tool or any other debugging proxy. While all requests that reached the WebDAV server Engine are logged, if the request failed before hitting the Engine you will not see it in a log. Usually this happens if the request failed during authentication stage.
Note that to capture requests using Fiddler on 'localhost' you must use 'localhost.fiddler' instead of 'localhost' when connecting to server, for example: http://localhost.fiddler:1234.
Exclude any client side issues. Finally there could be issues with client software that you are using, including with Microsoft miniredirector. Try to access server from any other machine. To get the idea if the problem is on the client or server side try also to reproduce the issue on ajaxbrowser.com.
You can post a part of the WebDAVLog.txt or fiddler log here or send it to IT Hit, it may give the idea of what is wrong.
I am using the formpost method of swift server to file upload. some time file get uploaded. But some time not.
On swift server log I am getting 499 httpcode. Please help me to solve this problem.
499 Client Closed Request (Nginx)
Used in Nginx logs to indicate when the connection has been closed by client while the server is still processing its request, making server unable to send a status code back.
Its your client side issue which has a time limit for processing. If the time exceeds and upload has not happened it terminates the connection/upload process. It has nothing to do with Swift.
Hope it helps.
I am writing a Drupal 7 module which is listening for HTTP POST messages to be sent by a 3rd party remote application. For testing I am sending messages using the Firefox Poster extension.
If I POST the message, the following code fails to place any value in my local vars (I get 'undefined index'):
$transId = urldecode($_POST['c2s_transaction_id']);
However, if I send the message using GET, the vars get populated fine with the following code:
$transId = urldecode($_REQUEST['c2s_transaction_id']);
This is true on both my local WAMP setup and on a shared hosting package.
I have never worked with HTTP POST messages before and have no idea where the problem might be. Could it be Drupal, the web server, or my code? Can anyone suggest how I might resolve this?
Many thanks,
Polly
Drupal removes the $_POST/$_GET in the system, just use $_REQUEST instead.