I have been playing with some tcpdump commands and egrep
tcpdump -i eth1 port sip -l -A | egrep -i 'User-Agent'
i leave this running on asterisk pbx server and I can see all the useragents flow down the screen.
What i would like to see is the user agent and the ip of the sip client
then ignore a few different types of user-agents so that when I am done I only see ip address and user-agents coming down the screen of unknown traffic.
Here is a example of the full sip packets from the command without the egrep. I do not have a example in it where the user agent of sipcli/v1.8 maybe later I can get that.
07:54:24.358716 IP xxx.xx.xx.xxx.5060 > 10.1.44.10.5060: SIP, length: 543
EH.;.5..8.y..UF.&..
.....'!SSIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK49b7b7d0;received=10.1.44.10;rport=5060
From: <sip:12345_3#voipprovider3.domain.com>;tag=as5afba40a
To: <sip:12345_3#voipprovider3.domain.com>;tag=as14777e11
Call-ID: 0e860af7278712754385ce784282c772#127.0.1.1
CSeq: 604 REGISTER
Server: voip.ms
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="voipprovider3.domain.com", nonce="7810c539"
Content-Length: 0
07:54:24.384512 IP 10.1.44.10.5060 > xxx.xx.xx.xxx.5060: SIP, length: 558
E`.Jrn..#..S&..
.UF......6..REGISTER sip:voipprovider3.domain.com SIP/2.0
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK6ef2d7d2;rport
Max-Forwards: 70
From: <sip:12345_3#voipprovider3.domain.com>;tag=as5afba40a
To: <sip:12345_3#voipprovider3.domain.com>
Call-ID: 0e860af7278712754385ce784282c772#127.0.1.1
CSeq: 605 REGISTER
User-Agent: unknown
Authorization: Digest username="12345_3", realm="voipprovider3.domain.com", algorithm=MD5, uri="sip:voipprovider3.domain.com", nonce="7810c539", response="5d6ac715deff942d1a3b22b39f83c0b1"
Expires: 120
Contact: <sip:s#10.1.44.10:5060>
Content-Length: 0
07:54:24.387070 IP xxx.xx.xx.xxx.5060 > 10.1.44.10.5060: SIP, length: 549
EH.A.6..8.y..UF.&..
.....-.GSIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK6ef2d7d2;received=10.1.44.10;rport=5060
From: <sip:12345_3#voipprovider3.domain.com>;tag=as5afba40a
To: <sip:12345_3#voipprovider3.domain.com>;tag=as14777e11
Call-ID: 0e860af7278712754385ce784282c772#127.0.1.1
CSeq: 605 REGISTER
Server: voip.ms
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 120
Contact: <sip:s#10.1.44.10:5060>;expires=120
Date: Tue, 22 Nov 2016 12:54:24 GMT
Content-Length: 0
07:54:24.813579 IP 10.1.44.10.5060 > xxx.xx.xx.xxx.5060: SIP, length: 551
E`.C_...#.0.&..
.UF....../..REGISTER sip:voipprovider.domain.com SIP/2.0
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK3b0c2176;rport
Max-Forwards: 70
From: <sip:12345#voipprovider.domain.com>;tag=as5b82aabf
To: <sip:12345#voipprovider.domain.com>
Call-ID: 6face5f36fdd29c31d3a10182e207048#127.0.1.1
CSeq: 604 REGISTER
User-Agent: unknown
Authorization: Digest username="12345", realm="voipprovider1.domain.com", algorithm=MD5, uri="sip:voipprovider.domain.com", nonce="236a06e2", response="13d3528c45792fb242a47f1c18b43879"
Expires: 120
Contact: <sip:s#10.1.44.10:5060>
Content-Length: 0
07:54:24.816319 IP xxx.xx.xx.xxx.5060 > 10.1.44.10.5060: SIP, length: 539
EH.7Jy..7.Ou.UF.&..
.....# .SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK3b0c2176;received=10.1.44.10;rport=5060
From: <sip:12345#voipprovider.domain.com>;tag=as5b82aabf
To: <sip:12345#voipprovider.domain.com>;tag=as15b40d21
Call-ID: 6face5f36fdd29c31d3a10182e207048#127.0.1.1
CSeq: 604 REGISTER
Server: voip.ms
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="voipprovider1.domain.com", nonce="168d0f22"
Content-Length: 0
07:54:24.842388 IP 10.1.44.10.5060 > xxx.xx.xx.xxx.5060: SIP, length: 551
E`.C_...#.0.&..
.UF....../..REGISTER sip:voipprovider.domain.com SIP/2.0
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK69d58133;rport
Max-Forwards: 70
From: <sip:12345#voipprovider.domain.com>;tag=as5b82aabf
To: <sip:12345#voipprovider.domain.com>
Call-ID: 6face5f36fdd29c31d3a10182e207048#127.0.1.1
CSeq: 605 REGISTER
User-Agent: unknown
Authorization: Digest username="12345", realm="voipprovider1.domain.com", algorithm=MD5, uri="sip:voipprovider.domain.com", nonce="168d0f22", response="724e79293e8d587a2b8106df991486d7"
Expires: 120
Contact: <sip:s#10.1.44.10:5060>
Content-Length: 0
07:54:24.899968 IP xxx.xx.xx.xxx.5060 > 10.1.44.10.5060: SIP, length: 545
EH.=Jz..7.On.UF.&..
.....)..SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK69d58133;received=10.1.44.10;rport=5060
From: <sip:12345#voipprovider.domain.com>;tag=as5b82aabf
To: <sip:12345#voipprovider.domain.com>;tag=as15b40d21
Call-ID: 6face5f36fdd29c31d3a10182e207048#127.0.1.1
CSeq: 605 REGISTER
Server: voip.ms
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 120
Contact: <sip:s#10.1.44.10:5060>;expires=120
Date: Tue, 22 Nov 2016 12:54:24 GMT
Content-Length: 0
Here is with the egrep and the line with the ip addresses on it. i really just want to show only the lines that show a user agent. this shows without useragent also.
tcpdump -i eth1 port sip -l -A | egrep -i 'User-Agent|SIP/2.0/UDP'
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK6fd0af5a;received=10.1.44.10;rport=5060
Via: SIP/2.0/UDP 158.85.70.151:5060;branch=z9hG4bK64939182;rport
User-Agent: VoipProvider
Via: SIP/2.0/UDP 158.85.70.151:5060;branch=z9hG4bK64939182;received=158.85.70.151;rport=42872
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK600d27fe;rport
User-Agent: Asterisk PBX
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK600d27fe;received=10.1.44.10;rport=5060
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK374f1905;rport
User-Agent: Asterisk PBX
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK374f1905;received=10.1.44.10;rport=5060
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK4ac13138;rport
User-Agent: Asterisk PBX
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK4ac13138;received=10.1.44.10;rport=5060
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK370927b1;rport
User-Agent: Asterisk PBX
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK370927b1;received=10.1.44.10;rport=5060
Via: SIP/2.0/UDP 185.40.4.96:5070;branch=z9hG4bK-ac834e0a1d92fc96bb7b4da395a5ead5;rport
User-Agent: sipcli/v1.8
Via: SIP/2.0/UDP 185.40.4.96:5070;branch=z9hG4bK-ac834e0a1d92fc96bb7b4da395a5ead5;received=185.40.4.96;rport=5070
Via: SIP/2.0/UDP 185.40.4.96:5070;branch=z9hG4bK-ac834e0a1d92fc96bb7b4da395a5ead5;received=185.40.4.96;rport=5070
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK7a1517ef
User-Agent: Asterisk PBX
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK7a1517ef;received=10.1.44.10;rport=5060
Via: SIP/2.0/UDP 185.40.4.96:5070;branch=z9hG4bK-ac834e0a1d92fc96bb7b4da395a5ead5;received=185.40.4.96;rport=5070
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK425ae339
User-Agent: Asterisk PBX
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK425ae339;received=10.1.44.10;rport=5060
Via: SIP/2.0/UDP 185.40.4.96:5070;branch=z9hG4bK-ac834e0a1d92fc96bb7b4da395a5ead5;received=185.40.4.96;rport=5070
Via: SIP/2.0/UDP 185.40.4.96:5070;branch=z9hG4bK-ac834e0a1d92fc96bb7b4da395a5ead5;received=185.40.4.96;rport=5070
Via: SIP/2.0/UDP 185.40.4.96:5070;branch=z9hG4bK-ac834e0a1d92fc96bb7b4da395a5ead5;received=185.40.4.96;rport=5070
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK7ac74b27
User-Agent: Asterisk PBX
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK7ac74b27;received=10.1.44.10;rport=5060
Via: SIP/2.0/UDP 185.40.4.96:5070;branch=z9hG4bK-ac834e0a1d92fc96bb7b4da395a5ead5;received=185.40.4.96;rport=5070
Via: SIP/2.0/UDP 185.40.4.96:5070;branch=z9hG4bK-ac834e0a1d92fc96bb7b4da395a5ead5;received=185.40.4.96;rport=5070
Via: SIP/2.0/UDP 185.40.4.96:5070;branch=z9hG4bK-ac834e0a1d92fc96bb7b4da395a5ead5;received=185.40.4.96;rport=5070
Via: SIP/2.0/UDP 185.40.4.96:5070;branch=z9hG4bK-ac834e0a1d92fc96bb7b4da395a5ead5;received=185.40.4.96;rport=5070
Via: SIP/2.0/UDP 185.40.4.96:5070;branch=z9hG4bK-ac834e0a1d92fc96bb7b4da395a5ead5;received=185.40.4.96;rport=5070
Via: SIP/2.0/UDP 10.1.44.10:5060;branch=z9hG4bK7723c051
User-Agent: Asterisk PBX
I would like to see something like this
sipcli/v1.8 185.40.4.96
you could try something like that:
tshark -Y 'sip.User-Agent == "foo bar"' -T fields -e sip.User-Agent -e sip.Contact
keep in mind that user-agent is optional in sip packets.
Related
Can anyone solve the way I can generate akamai streaming token from the browser when the android app is not available?
I get this string from the app :
<--
POST /api/tibo324/getakamaitoken HTTP/1.1
Content-Length: 328
Content-Type: application/x-www-form-urlencoded
Host: tibodrm.appspot.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)
<--
auth=84Kwfr741QQv%252BnUMXtW%252FcbZ6aWNQKN0mCAVccmjo%252FXaf6PaB2pz7j3QqAlxHaj%252Fut%252Bu3vSzDt8NO%250AKqNBIgM7ckBedzNMkGOBRtlFfi3gAUuUzYvFN7U9ClHQKKWtfL%252F%252FyB2o1qyvGc2tY8i8lud%252F3tqg%250AhyjUvUD3Bib11V9aQqx8JOBslArMz%252FUaXLR0skPUETIeQatFmGmhFoyuyPhgbg%253D%253D%250A&AppID=v%252B10zWNKL8RJ8SY6LUSZXg%253D%253D%250A
-->
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 26 Dec 2017 22:24:09 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 118
Vary: Accept-Encoding
X-Powered-By: Express
ETag: W/"76-zi4HHRQAuAUejh/FF9M5ZFJtPek"
Via: 1.1 google
Alt-Svc: hq=":443"; ma=2592000; quic=51303431; quic=51303339; quic=51303338; quic=51303337; quic=51303335,quic=":443"; ma=2592000; v="41,39,38,37,35"
-->
?__token__=ip=00.000.00.000~exp=1514332929~acl=*~hmac=e9afdfe9f6b41c0ca14a16bc60a11253aecd432243789144c1ebaa70f23c615e
When I try to fetch the following URL:
https://tibodrm.appspot.com/api/tibo324/getakamaitoken?auth=84Kwfr741QQv%2BnUMXtW%2FcbZ6aWNQKN0mCAVccmjo%2FXaf6PaB2pz7j3QqAlxHaj%2FuFjEcIocduH6Z%0Awc5ZzKaqnmHhinePCNCcvQfh68bi2UvbZq04lBalY0job9%2FyVeuV1kh4hzWnP8sVuRozO27rFhSY%0AmDB8ck%2FuN0SqKEoxzycGUGhaZy3bjy88%2BhhwEMQknGNJ2j2JdMIHMT0AcLTFoQ%3D%3D%0A&AppID=v%2B10zWNKL8RJ8SY6LUSZXg%3D%3D%0A
I get a response in the browser:
Cannot GET /api/tibo324/getakamaitoken
What am I missing?
The answer is in your question: you can't GET the URL because it's accessed via POST only. And it looks like the POST requires an authentication string that's generated via the app. Making a POST without any data returns a descriptive error string:
$ http POST https://tibodrm.appspot.com/api/tibo324/getakamaitoken
HTTP/1.1 200 OK
Alt-Svc: hq=":443"; ma=2592000; quic=51303431; quic=51303339; quic=51303338; quic=51303337; quic=51303335,quic=":443"; ma=2592000; v="41,39,38,37,35"
Content-Encoding: gzip
Content-Type: application/json; charset=utf-8
Date: Wed, 27 Dec 2017 21:44:19 GMT
ETag: W/"31-zIZow+wVfq5Z3stS2NUNRdvP0go"
Server: nginx
Transfer-Encoding: chunked
Vary: Accept-Encoding
Via: 1.1 google
X-Powered-By: Express
{
"description": "no token at all",
"isValid": false
}
The inability to access the token generator through unauthenticated web calls is usually by design as the token is a protective tool Akamai provides customers to prevent access to content outside of the content provider's control.
In short, the content provider you're looking at doesn't want you to access their video outside of their application. If the application isn't able to access the video then you should reach out to the content provider to get that issue fixed rather than trying to circumvent their security scheme.
Earlier I was using heroku to server static assets. Then I decided to use cloud front to serve static assets for my rails(5.0.2) app on heroku. After configuring it all seemed good but for fonts chrome was throwing this error .
Access to Font at 'https://eeeeeee.cloudfront.net/assets/fontawesome-webfont-18e6b5ff511b90edf098e62ac45ed9d6673a3eee10165d0de4164d4d02a3a77f.woff?v=3.2.1' from origin 'https://staging-example.herokuapp.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://staging-example.herokuapp.com' is therefore not allowed access.
I googled the issue and found some info here 'Cloudfront CORS issue serving fonts on Rails application'. As per the first answer I followed all the steps. My rock-cors configuration is
config.middleware.insert_before 0, Rack::Cors do
allow do
origins %w[
https://staging-example.herokuapp.com
http://staging-example.herokuapp.com
]
resource '/assets/*'
end
end
which is there in application.rb
Still I am getting this issue
Access to Font at 'https://eeeeeee.cloudfront.net/assets/fontawesome-webfont-18e6b5ff511b90edf098e62ac45ed9d6673a3eee10165d0de4164d4d02a3a77f.woff?v=3.2.1' from origin 'https://staging-example.herokuapp.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://staging-example.herokuapp.com' is therefore not allowed access.
Using curl to look for headers I got this out puts
when hitting my url
curl -H "Origin: https://staging-example.herokuapp.com" -I https://staging-example.herokuapp.com/assets/fontawesome-webfont-18e6b5ff511b90edf098e62ac45ed9d6673a3eee10165d0de4164d4d02a3a77f.woff?v=3.2.1
HTTP/1.1 200 OK
Server: Cowboy
Date: Sat, 17 Jun 2017 13:49:11 GMT
Connection: keep-alive
Access-Control-Allow-Origin: https://staging-example.herokuapp.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 1728000
Access-Control-Allow-Credentials: true
Last-Modified: Tue, 02 May 2017 11:13:21 GMT
Content-Type: application/font-woff
Vary: Origin
Content-Length: 43572
Via: 1.1 vegur
When hitting direclty to cdn url
curl -H "Origin: https://staging-example.herokuapp.com" -I https://eeeeeee.cloudfront.net/assets/fontawesome-webfont-18e6b5ff511b90edf098e62ac45ed9d6673a3eee10165d0de4164d4d02a3a77f.woff?v=3.2.1
HTTP/1.1 200 OK
Content-Type: application/font-woff
Content-Length: 43572
Connection: keep-alive
Server: Cowboy
Date: Sat, 17 Jun 2017 13:19:04 GMT
Access-Control-Allow-Origin: https://staging-example.herokuapp.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Max-Age: 1728000
Access-Control-Allow-Credentials: true
Last-Modified: Tue, 02 May 2017 11:13:21 GMT
Via: 1.1 vegur, 1.1 21e1fe3458bce196f8eb1701ebbbce53.cloudfront.net (CloudFront)
Vary: Origin
Age: 2023
X-Cache: Hit from cloudfront
X-Amz-Cf-Id: zFXm3g53TJ4Nm6a9oH0yjVq-KUvvPoQI1chz_XN8nnaEd-p-TtQPNg==
Clearly the headers are present then why chrome is throwing that error. Kindly help.
You need to add preflight headers to your application_controller.rb
:
before_action :cors_set_access_control_headers
def cors_set_access_control_headers
headers['Access-Control-Allow-Origin'] = '*'
headers['Access-Control-Allow-Methods'] = 'POST, PUT, DELETE, GET, PATCH, OPTIONS'
headers['Access-Control-Request-Method'] = '*'
headers['Access-Control-Allow-Headers'] = 'Origin, X-Requested-With, Content-Type, Accept, Authorization'
end
I have a rails 4 backend using DeviseTokenAuth and an AngularJS frontend using ngTokenAuth.
When frontend and backend are deployed on the same domain the authentication works perfectly.
When testing on localhost, with both the backend and the frontend running on localhost on two different ports the sign_in request completes with 200 OK but the response doesn't contain Set-Cookie header and so the client remains unauthenticated for the following requests.
Down here you can see a copy of the headers received in the sign_in response in both scenarios.
The problem is the same also if I try to authenticate from a frontend running locally to the RAILS backend deployed on server.
The CORS headers are configured like this on the server and everything seems fine to me about cross origin:
config.middleware.insert_before 0, "Rack::Cors" do
allow do
origins '*'
resource '*', :headers => :any, :methods => [:get, :post, :options]
end
end
Deployed on server
Accept-Ranges:bytes
Access-Control-Allow-Credentials:true
Access-Control-Allow-Methods:GET, POST, OPTIONS
Access-Control-Allow-Origin:example.org
Access-Control-Expose-Headers:
Access-Control-Max-Age:1728000
access-token:XXXXXXXXXXOI9s2x0IuVMA
Age:0
Cache-Control:max-age=0, private, must-revalidate
client:XXXXXXXXXXAP2TsoBZTnjg
Connection:keep-alive
Content-Type:application/json; charset=utf-8
Date:Thu, 04 May 2017 09:28:17 GMT
ETag:W/"XXXXXXXXXXc86bb292d476d2366d3742"
expiry:1495099697
Server:nginx/1.10.0 (Ubuntu)
Set-Cookie:_differenthood_session=ZE1NWndTUUVmMkNDbWRWckNNbkpKdWh6SVdaVTFlaGN6XXXXXXXXXXcrb2EzSGd3SFQvN2h3Z2IxOE9BMVYrTjV6YmsvRXpWNmN4T213R2V3MEJ1WWc9PS0tbU01Ymt6YkdOc0VIUTFCK1NUVFlMZz09--861a3aebd1d79f224d9ad810a88e5d5f23e114c0; path=/; HttpOnly
token-type:Bearer
Transfer-Encoding:chunked
uid:login#email.com
Vary:Origin
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Request-Id:c935b76c-d173-48ce-b21c-5e694845148b
X-Runtime:0.629113
X-XSS-Protection:1; mode=block
Testing on localhost
Access-Control-Allow-Credentials:true
Access-Control-Allow-Methods:GET, POST, OPTIONS
Access-Control-Allow-Origin:http://localhost:9000
Access-Control-Expose-Headers:
Access-Control-Max-Age:1728000
Access-Token:XXXXXXXXXXXAiR5CQmwYpQ
Cache-Control:max-age=0, private, must-revalidate
Client:XXXXXXXXXXq2UC7GXE0qbw
Connection:Keep-Alive
Content-Length:418
Content-Type:application/json; charset=utf-8
Date:Thu, 04 May 2017 09:27:20 GMT
Etag:W/"XXXXXXXXXX37381b8c1637b2ea1bba96"
Expiry:1495099640
Server:WEBrick/1.3.1 (Ruby/2.2.6/2016-11-15)
Token-Type:Bearer
Uid:login#email.com
Vary:Origin
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Request-Id:3ef1f652-b29f-4fe7-bbb9-3de47f1acddf
X-Runtime:0.653264
X-Xss-Protection:1; mode=block
Nevermind sorry.
I read the documentation deeper (https://github.com/lynndylanhurley/devise_token_auth#cors) and found the suggested CORS configuration that fixed the problem for me.
By adding:
:expose => ['access-token', 'expiry', 'token-type', 'uid', 'client'],
to the CORS configuration posted in the question, the problem is resolved.
How do you configure nginx to return a valid Content-Length header when responding to a HTTP HEAD request? Currently my server returns this:
curl --head http://example.com/myfile.xml
HTTP/1.1 200 OK
Date: Tue, 23 Aug 2016 13:49:46 GMT
Content-Type: text/xml
Set-Cookie: __cfduid=da2daeaa59809916192f7ac0645d3a3e91471960186; expires=Wed, 23-Aug-17 13:49:46 GMT; path=/; domain=.example.com; HttpOnly
Last-Modified: Mon, 22 Aug 2016 16:20:26 GMT
Vary: Accept-Encoding
ETag: W/"57bb264a-5442b26a"
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Access-Control-Allow-Origin: *
Access-Control-Request-Method: *
Cache-Control: public
Server: cloudflare-nginx
CF-RAY: 9dac40-LHR
X-Cache: MISS from Squid
Via: 1.1 Squid (squid/3.2.14)
I must send the Content-Length header with the response to HEAD (if I don't, the service that checks that URL will never see that the file was changed, and will not download the new version). How do you set it up?
I might be wrong, but nginx probably isn't showing the content-length because of nature of dynamic content generated by Rails's application server.
You can ask Rails to send that in response header. In your Rails application's config/application.rb add the following middleware:
config.middleware.use "Rack::ContentLength"
This should return the content-length header in response.
I'm trying to setup a Docker container running freeSWITCH so I can deploy it on a Debian server.
For developing, I use a Mac running the freeSWITCH container within boot2docker.
I need the container to work in both these environments.
I manage to connect to the FS server with a softphone and place a call but after 32 seconds, the call drops.
freeswitch#internal> version
FreeSWITCH Version 1.4.15-1~64bit (-1 64bit)
This is the SIP 200 OK packet that FS sends and expects an answer to:
14 0.029449000 192.168.59.103 192.168.59.3 SIP/SDP 1312 Status: 200 OK |
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.141:49822;rport=49822;branch=z9hG4bKPjFf3iaNQ0tDY1fySiz1zGSEXSVFpZeE2b;received=192.168.59.3
From: "1000" <sip:1000#192.168.59.103>;tag=tNpJHmkYg0ke5GYyvIhkdBSIMM.ujzXE
To: <sip:5000#192.168.59.103>;tag=6N3793jeayeUe
Call-ID: 4wWTcxr9Q4OqlgT2Fs-8SeOkLhVYXTLb
CSeq: 10007 INVITE
Contact: <sip:5000#172.17.0.6:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.4.15-1~64bit
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 333
Remote-Party-ID: "5000" <sip:5000#192.168.59.103>;party=calling;privacy=off;screen=no
v=0
o=FreeSWITCH 1422731206 1422731207 IN IP4 172.17.0.6
s=FreeSWITCH
c=IN IP4 172.17.0.6
t=0 0
m=audio 16386 RTP/SAVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp:16387 IN IP4 172.17.0.6
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:/NTeSA7Od0+1Uo1/3wIclZwEiKJ+R4Mh8gyTx+5O
Then this happens:
1745 32.031059000 192.168.59.103 192.168.59.3 SIP 664 Request: BYE sip:29716085#192.168.59.3:49822 |
BYE sip:29716085#192.168.59.3:49822 SIP/2.0
Via: SIP/2.0/UDP 172.17.0.6;rport;branch=z9hG4bK0m429X0ac150r
Max-Forwards: 70
From: <sip:5000#192.168.59.103>;tag=6N3793jeayeUe
To: "1000" <sip:1000#192.168.59.103>;tag=tNpJHmkYg0ke5GYyvIhkdBSIMM.ujzXE
Call-ID: 4wWTcxr9Q4OqlgT2Fs-8SeOkLhVYXTLb
CSeq: 71037748 BYE
Contact: <sip:5000#172.17.0.6:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.4.15-1~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Reason: SIP;cause=408;text="ACK Timeout"
Content-Length: 0
I'm guessing FS never receives an answer from the softphone because of the various NAT layers and drops the call, assuming it didn't connect.
192.168.1.141 is my Mac's IP address on the LAN (as shown in the VIA for the 200 OK packet)
192.168.59.103 is the boot2docker VM
192.168.59.3 is my Mac on the boot2docker virtual network
172.17.0.xxx is the FS server's IP address on the Docker network (this IP changes, depending on how many containers are/were running before)
This is what I have on my sip_profiles/internal.xml
<param name="rtp-ip" value="$${local_ip_v4}"/>
<!-- ip address to bind to, DO NOT USE HOSTNAMES ONLY IP ADDRESSES -->
<param name="sip-ip" value="$${local_ip_v4}"/>
<param name="hold-music" value="$${hold_music}"/>
<param name="apply-nat-acl" value="nat.auto"/>
<!-- Docker NAT magic -->
<param name="ext-sip-ip" value="$${external_sip_ip}"/>
<param name="ext-rtp-ip" value="$${external_rtp_ip}"/>
And in my vars.xml
<X-PRE-PROCESS cmd="set" data="external_rtp_ip=192.168.59.103"/>
<X-PRE-PROCESS cmd="set" data="external_sip_ip=192.168.59.103"/>
From fs_cli:
freeswitch#internal> eval ${external_rtp_ip}
192.168.59.103
freeswitch#internal> eval ${external_sip_ip}
192.168.59.103
freeswitch#internal> eval ${ext-rtp-ip}
-ERR no reply
freeswitch#internal> eval ${ext-sip-ip}
-ERR no reply
I have set ports 16384 to 16484 UDP for RTP traffic, 5060, 5070, 5080 UDP & TCP for SIP, both in FS and in the container.
An echo test reveals that audio flows both ways.
Any idea what is happening and how to fix?
I had a similar problem with my FreeSwitch installation and I solved it by configuring the switch to constantly ping the registered softphones so as to keep the NAT firewall channels open. Here are the settings that did it for me:
<param name="nat-options-ping" value="true"/>
<param name="all-reg-options-ping" value="true"/>
<!-- One successful options ping is enough to verify that a phone is reachable -->
<param name="sip-user-ping-min" value="1"/>
<!-- Three pings need to be lost to consider the phone disconnected -->
<param name="sip-user-ping-max" value="4"/>
<param name="unregister-on-options-fail" value="true"/>
<!-- Freeswitch is coded to send
pings at variable intervals with the mean value determined by the
variable below and a normal distribution with a deviation of half the
interval value. -->
<param name="ping-mean-interval" value="15"/>
They go to sip_profiles/internal.xml.
Ok so here is an update.
It turns out the problem was because FS wasn't able to detect its IP properly and the packets it was sending back contained to the wrong IP.
I came up with this script as part of my container boot sequence:
https://github.com/Coaxial/mushimushi/blob/a29ae537314e89bc7f9808c2bd7fdb4917eafa04/lib/freeswitch_conf/start.sh#L7-L21
I then include the resulting XML file into the general config: https://github.com/Coaxial/mushimushi/blob/a29ae537314e89bc7f9808c2bd7fdb4917eafa04/lib/freeswitch_conf/freeswitch.xml#L3
This way I can reference the variables to configure the relevant Sofia profiles: https://github.com/Coaxial/mushimushi/blob/a29ae537314e89bc7f9808c2bd7fdb4917eafa04/lib/freeswitch_conf/autoload_configs/sofia.conf.xml#L29-L32
This works when run in boot2docker but isn't battle tested in "vanilla" docker yet.