Trying to make a videoaudio call with SipML5 and Asterisk13, one user in Chorme and the other Firefox, but right after "Ringing"(180) the caller receives "Not acceptable here"(488).
Asterisk messages:
[Jan 23 11:38:27] NOTICE[11127][C-00000004] chan_sip.c: Received AVP profile in audio answer but AVPF is enabled, disabling: audio 36436 RTP/AVP 111 8 0 101
[Jan 23 11:38:27] WARNING[11127][C-00000004] chan_sip.c: We are requesting SRTP for audio, but they responded without it!
So about the 488 I found in several pages:
488 Not Acceptable Here -
The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere.
A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request.
and
You have not enabled AVPF support in the peer, user, or friend entry using "avpf=yes" or have not allowed a codec that is supported by the caller.
but I did't found anywhere a way to fix this. Yep, noob in SIP.
The best i tried was to change my peer in sip.conf (add the avpf=true), but not even the asterisk messages changed.
Is it a codec problem? If so, how do I change for one that works in this case?
If not, whats going on here? Kinda loosing my mind already. ^^"
Probably, Asterisk is following the RFC's and you need to use SAVP / SAVPF profiles when negotiating secure SRTP sessions.
Related
I was running a asterisk 11.5 with no error. After installed Opus codec with patch in my asterisk
btw i am using browser based sip softphone jssip
Now whenever I am making audio call between 2 peer, no call is getting establish and throwing below errors:
btw i am using browser based sip softphone jssip
[Sep 29 09:27:36] WARNING[17065][C-00000003]: sip/sdp_crypto.c:173 sdp_crypto_activate: Could not set SRTP policies
[Sep 29 09:27:36] WARNING[17065][C-00000003]: sip/sdp_crypto.c:173 sdp_crypto_activate: Could not set SRTP policies
[Sep 29 09:27:36] WARNING[17065][C-00000003]: chan_sip.c:11100 process_sdp_a_audio: Got Opus minptime=10
[Sep 29 09:27:36] WARNING[17065][C-00000003]: chan_sip.c:10437 process_sdp: Rejecting secure audio stream without encryption details: audio 17002 RTP/SAVPF 111 103 104 0 8 106 105 13 126
[1000]
secret=test123
context=local
host=dynamic
trustrpid=yes
sendrpid=no
type=friend
qualify=yes
qualifyfreq=600
transport=udp,wss,ws
encryption=yes
dial=SIP/8000
callerid=testuser <8000>
callcounter=yes
avpf=yes
icesupport=yes
directmedia=no
Can any one cooperate?
Use tcpdump or wireshark to look at the packets, and make sure that they're actually encrypted packets. I looks like it may be rejecting them because it's not SRTP. However, that is only an educated guess. Additionally at the asterisk command line you might want to look at rtp set debug on.
You may look to Asterisk 12 for Opus support, where it will be officially supported, or so it seems from the development activity for Asterisk 12.
Here's the reference to the issue and discussion of the fix. And you can see that it's been approved by the review board here.
I, too, am interested in using Opus. However, without knowing what patch you are using, and the stability of said patch -- it may be difficult (and rather time consuming) to give specific instruction here. I would recommend reporting the issue to the person/group who released the patch as it may help the community project (if it is such).
I m trying to access a website using sim900 GSM module.
This is the list of commands
AT+CSQ
+CSQ: 16,0
OK
AT+HTTPINIT
OK
AT+HTTPPARA="CID",1
OK
AT+HTTPPARA="URL","www.google.com"
OK
AT+HTTPACTION=0
OK
+HTTPACTION:0,601,0
AT+HTTPACTION=0
OK
+HTTPACTION:0,601,0
Unable to access google. 601 code shows Network error.
How to get rid of this error?
You need to setup the connection to the bearer. Here are the minimum setup commands that have worked for me (based on trial/error and searching around on the internet).
AT+SAPBR=3,1,"APN","wap.cingular"
AT+SAPBR=1,1
The correct value for the APN may be different for you, depending on your network and service provider. I'm using AT&T prepaid SIM cards. Once that's working, then you can do the HTTP setup commands as you already have...
AT+HTTPINIT
AT+HTTPPARA="URL","http://www.google.com"
AT+HTTPACTION=0
Status codes above 600 (and some in the 500 range) are unassigned in the HTTP standard. In the AT command manual for the SIM908, status meanings are given in the notes on the HTTPACTION command:
600 Not HTTP PDU
601 Network Error
602 No memory
603 DNS Error
604 Stack Busy
You can query the bearer connection status of CID 1 with AT+SAPBR=2,1 and the related parameters with AT+SAPBR=4,1. You can also check that you're attached to the GPRS network with AT+CGATT?. If everything indicates that you are connected and you are still getting a 601 status code, then check that your service plan has data and that it hasn't run out. I have found that even when my account has a few hundred k of data showing on the balance that I start to get a 601 status until I add more data to my prepaid phone plan. If the SIM module has been on the whole time and you add more data, you'll need to close and re-open your connection (AT+SAPBR=0,1 followed by AT+SAPBR=1,1) and then your HTTP* commands will start working again without having to set the HTTPPARA settings again and without having to restart with HTTPINIT.
I have found that when an http call is made to an https only website it will throw a 601 error on the sim. Beware some sim devices have ssl and some don't. Use AT+HTTPSSL=? to interrogate. device with ssl will respond like, 'HTTPSSL 1'. If you get an error your device doesn't have ssl. This took some work with the factory for me to determine this.
You must also use to hit ssl site. I am using the wifi101 ssl client.
fona.setHTTPSRedirect(true);
dy3
I have encoutered this error as well. The cause of the problem may be that there is not enough money in the phone number account. You may check it.
601 is some custom implemented Error code.
Here is the list of standard HTTP Status codes
+HTTPACTION:0,601,0
The above AT response code (601) for HTTP session start indicates that
there is a network error. Then make sure that the PDP context is setup
properly.
source
https://m2msupport.net/m2msupport/at-command-for-http-functions-for-remote-server-data-access/
I have spent many hours with this module right now.
My experience is that when you dont get a 200 reply from remote server, you should check IP address to verify you are still on the network sendng a ping to a working server (AT+CIPPING="XX.XX.XX.XX").
If it succeeds: Try AT+SAPBR=2,1 and AT+CIFSR. You should get same address for both commands.
If you dont get same address, login again to the netword/service with AT+CIPCSGP=1, "yourapn.com", "user", "password".
If nothing works, power down the module. Wait a couple of minutes, and restart again.
Just in case someone is affected by this problem and stumbles on this post 4 years later: in my case the module had a small "sticker" type antenna and it got somehow damaged.
I could connect to the network but when I tried to use HTTP over the GPRS networks I only got return code 601 (network error) or 603 (failed to resolve DNS).
Once I replaced the antenna with a new one, everything worked perfectly.
Again, in case somebody has the same problem. In my case it was a typo in url:
AT+HTTPPARA="URL"," http://www.google.com"
Did you notice the space before http? For several hours, I didn't notice it too.
Usually after this command AT+SAPBR=3,1,"CONTYPE","GPRS" you enter your "APN", "USR" & "PWD" details also using SAPBR=3,1 etc. These details must match the SIM card / mobile phone provider.
Then it is recommended to check that your device has now received an IP address. Sometimes this is not straight away. Use AT+SAPBR=2,1 to query and this will return your IP address which you should check for confirmation.
Once you have IP address you can enter AT+HTTPINIT, AT+HTTPPARA="CID",1 etc.
Now to use GET you have to include a "?" after the URL to provide your php script with a key=value pairing.
Thus in your case it is something like, AT+HTTPPARA="URL","http://<Public_Ip_Address>:8080/folder/savedata.php?A=1001" where A is the key and 1001 is the value.
Now send the AT+HTTPACTION=0 and you should get a +HTTPACTION: 0,200,1000 response where 200 is the OK and 1000 is the payload size. AT+HTTPREAD will allow you to read the response if it is required.
Change URL. 601 is a URL has been moved. Is a redirect.
What's the maximum length of an HTTP GET request?
Is there a response error defined that the server can/should return if it receives a GET request that exceeds this length?
This is in the context of a web service API, although it's interesting to see the browser limits as well.
The limit is dependent on both the server and the client used (and if applicable, also the proxy the server or the client is using).
Most web servers have a limit of 8192 bytes (8 KB), which is usually configurable somewhere in the server configuration. As to the client side matter, the HTTP 1.1 specification even warns about this. Here's an extract of chapter 3.2.1:
Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.
The limit in Internet Explorer and Safari is about 2 KB, in Opera about 4 KB and in Firefox about 8 KB. We may thus assume that 8 KB is the maximum possible length and that 2 KB is a more affordable length to rely on at the server side and that 255 bytes is the safest length to assume that the entire URL will come in.
If the limit is exceeded in either the browser or the server, most will just truncate the characters outside the limit without any warning. Some servers however may send an HTTP 414 error.
If you need to send large data, then better use POST instead of GET. Its limit is much higher, but more dependent on the server used than the client. Usually up to around 2 GB is allowed by the average web server.
This is also configurable somewhere in the server settings. The average server will display a server-specific error/exception when the POST limit is exceeded, usually as an HTTP 500 error.
You are asking two separate questions here:
What's the maximum length of an HTTP GET request?
As already mentioned, HTTP itself doesn't impose any hard-coded limit on request length; but browsers have limits ranging on the 2 KB - 8 KB (255 bytes if we count very old browsers).
Is there a response error defined that the server can/should return if it receives a GET request exceeds this length?
That's the one nobody has answered.
HTTP 1.1 defines status code 414 Request-URI Too Long for the cases where a server-defined limit is reached. You can see further details on RFC 2616.
For the case of client-defined limits, there isn't any sense on the server returning something, because the server won't receive the request at all.
Browser limits are:
Browser Address bar document.location
or anchor tag
---------------------------------------------------
Chrome 32779 >64k
Android 8192 >64k
Firefox >64k >64k
Safari >64k >64k
Internet Explorer 11 2047 5120
Edge 16 2047 10240
Want more? See this question on Stack Overflow.
A similar question is here: Is there a limit to the length of a GET request?
I've hit the limit and on my shared hosting account, but the browser returned a blank page before it got to the server I think.
Technically, I have seen HTTP GET will have issues if the URL length goes beyond 2000 characters. In that case, it's better to use HTTP POST or split the URL.
As already mentioned, HTTP itself doesn't impose any hard-coded limit on request length; but browsers have limits ranging on the 2048 character allowed in the GET method.
Yes. There isn't any limit on a GET request.
I am able to send ~4000 characters as part of the query string using both the Chrome browser and curl command.
I am using Tomcat 8.x server which has returned the expected 200 OK response.
Here is the screenshot of a Google Chrome HTTP request (hiding the endpoint I tried due to security reasons):
RESPONSE
Just switched some downloads over to the Akamai CDN network and I'm seeing some strange stuff in the log files they deliver. A number of entries have the status code 000. When I asked them they said that 000 is the status when the client disconnects without transferring the entire file. Since 000 doesn't appear to be a valid HTTP response code (from the RFC), I have to wonder if that's right.
There's a knowledge base article (requires login) which lists their log values:
Log Delivery Services (LDS) LDS will show a 000 for any 200 or 206
responses with a client abort: the object was served correctly from
the origin or edge, but the end-user terminated the
connection/transaction before it completed.
This is indeed a custom status because the standard log format doesn't include a field which can indicate a client abort.
000 is a common code to use when no HTTP code was received due to a network error. According to a knowledge base article for Amazon CloudFront, 000 also means that the client disconnected before completing the request for that service.
It normally means: No valid HTTP response code
(ie: Connection failed, or was aborted before any data happened).
I would guess that their are either network issues or Akamai isn't managing their webservers correctly.
So, I have a Blackberry 9000 application doing simple networking using HttpConnection. Everything works fine normally, when I go to urls of the form:
http://url.com
But I've discovered that I need to test this in wifi only situations (that is, without a BES or equivalent in sight). After some digging, I discovered that I need to add:
;interface=wifi
To all of my URLS, of the form:
http://url.com;interface=wifi
However, I'm noticing that this does not actually work, it gives me back a HTTP error 406. Which according to wiki is a:
406 Not Acceptable
The requested resource is only capable of generating content not acceptable according to the Accept headers sent in the request.[2]
Am I doing something completely wrong? Does Blackberry wrap wifi only requests in headers that require particularly formatted websites?
As explained on this page, you also need add "deviceside=true" to the URL.
To specify that the underlying TCP
connection should be opened directly
from the handheld, set this parameter
to "true". Specify "deviceside=false"
when receiving or sending data through
the BlackBerry MDS Connection Service.
So your full URL would be:
http://url.com;interface=wifi;deviceside=true