I am trying to authenticate an application from a client to a Lync server 2013 softphone using the NTLM method in SIP. But I'm not sure how to do the AUTHENTICATE_MESSAGE part of it.
here is what I am doing for the Authorization part of the SIP message :
if CSeq = '1' then
begin
// First message is to get the server authentication methods and realm/targetname
result := result + '';
end
else if CSeq = '2' then
begin
// On the second message, I pass the realm and targetname, corresponding to the negociate message
result := result + 'Authorization: NTLM qop="'+mQop+'", realm="'+mRealm+'", targetname="'+mTargetName+'", version='+mVersion+', gssapi-data="" ' + #13#10;
end
else if CSeq = '3' then
begin
if StrToInt(mVersion) > 3 then
begin
result := result + 'Authorization: NTLM opaque="'+mOpaque+'", qop="'+mQop+'", realm="'+mRealm+'", targetname="'+mTargetName+'", '+
'gssapi-data="'+**ProcessedChallenge**+'", version='+mVersion+', crand="'+CNONCE+'", '+
'cnum="'+NONCECOUNT+'", response="'+**response**+'"' + #13#10;
end
else
begin
result := result + 'Authorization: NTLM opaque="'+mOpaque+'", qop="'+mQop+'", realm="'+mRealm+'", targetname="'+mTargetName+'", '+
'gssapi-data="'+**ProcessedChallenge**+'", version='+mVersion + #13#10;
end;
end
The thing is, I'm not sure of how to generate the "ProcessedChallenge" and "response" value in the third message. The rest seems to be ok, but just in case, here are the traces :
REGISTER sip:novotest.ca SIP/2.0
Via: SIP/2.0/TLS 192.168.20.180:5061
Max-Forwards: 70
Supported: replaces
Contact: <sip:192.168.20.180:5061;transport=tls>
To: <sip:mcote#novotest.ca>
From: <sip:mcote#novotest.ca>;tag=39539C4FEE9F427D8739BE8E5CD813FB;epid=000C299855EC
Call-ID: 82C61A739E594A09934681B2A13B1A8D
CSeq: 1 REGISTER
Expires: 3600
User-Agent: KOMUTEL SIP
Content-Length: 0
SIP/2.0 401 Unauthorized
Date: Mon, 03 Feb 2014 20:03:12 GMT
WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="qa121vm179.Novotest.ca", version=4
WWW-Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/qa121vm179.Novotest.ca", version=4
WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="qa121vm179.Novotest.ca", version=4, sts-uri="https://qa121vm179.novotest.ca:443/CertProv/CertProvisioningService.svc"
From: <sip:mcote#novotest.ca>;tag=39539C4FEE9F427D8739BE8E5CD813FB;epid=000C299855EC
To: <sip:mcote#novotest.ca>;tag=FA72F83E7EA12109F5E9C2E8F087DA00
Call-ID: 82C61A739E594A09934681B2A13B1A8D
CSeq: 1 REGISTER
Via: SIP/2.0/TLS 192.168.20.180:5061;ms-received-port=5061;ms-received-cid=164200
Server: RTC/5.0
Content-Length: 0
REGISTER sip:novotest.ca SIP/2.0
Via: SIP/2.0/TLS 192.168.20.180:5061
Max-Forwards: 70
Supported: replaces
Contact: <sip:192.168.20.180:5061;transport=tls>
To: <sip:mcote#novotest.ca>
From: <sip:mcote#novotest.ca>;tag=39539C4FEE9F427D8739BE8E5CD813FB;epid=000C299855EC
Call-ID: 82C61A739E594A09934681B2A13B1A8D
CSeq: 2 REGISTER
Expires: 3600
User-Agent: KOMUTEL SIP
Supported: gruu-10
Authorization: NTLM qop="auth", realm="SIP Communications Service", targetname="qa121vm179.Novotest.ca", version=4, gssapi-data=""
Content-Length: 0
SIP/2.0 401 Unauthorized
Date: Mon, 03 Feb 2014 20:03:12 GMT
WWW-Authenticate: NTLM opaque="AF511061", gssapi-data="TlRMTVNTUAACAAAAAAAAADgAAADzgpjixfrJRZMjjbQAAAAAAAAAAKAAoAA4AAAABgOAJQAAAA8CABAATgBPAFYATwBUAEUAUwBUAAEAFABRAEEAMQAyADEAVgBNADEANwA5AAQAFgBOAG8AdgBvAHQAZQBzAHQALgBjAGEAAwAsAHEAYQAxADIAMQB2AG0AMQA3ADkALgBOAG8AdgBvAHQAZQBzAHQALgBjAGEABQAWAE4AbwB2AG8AdABlAHMAdAAuAGMAYQAHAAgAlvq/9xohzwEAAAAA", targetname="qa121vm179.Novotest.ca", realm="SIP Communications Service", version=4
From: <sip:mcote#novotest.ca>;tag=39539C4FEE9F427D8739BE8E5CD813FB;epid=000C299855EC
To: <sip:mcote#novotest.ca>;tag=FA72F83E7EA12109F5E9C2E8F087DA00
Call-ID: 82C61A739E594A09934681B2A13B1A8D
CSeq: 2 REGISTER
Via: SIP/2.0/TLS 192.168.20.180:5061;ms-received-port=5061;ms-received-cid=164200
Server: RTC/5.0
Content-Length: 0
REGISTER sip:novotest.ca SIP/2.0
Via: SIP/2.0/TLS 192.168.20.180:5061
Max-Forwards: 70
Supported: replaces
Contact: <sip:192.168.20.180:5061;transport=tls>
To: <sip:mcote#novotest.ca>
From: <sip:mcote#novotest.ca>;tag=39539C4FEE9F427D8739BE8E5CD813FB;epid=000C299855EC
Call-ID: 82C61A739E594A09934681B2A13B1A8D
CSeq: 3 REGISTER
Expires: 3600
User-Agent: KOMUTEL SIP
Supported: gruu-10
Authorization: NTLM opaque="AF511061", qop="auth", realm="SIP Communications Service", targetname="qa121vm179.Novotest.ca", gssapi-data="TlRMTVNTUAADAAAAGAAYAIoAAAAYABgAogAAABYAFgBAAAAAIgAiAFYAAAASABIAeAAAAAAAAAAAAAAABYIAAE4AbwB2AG8AdABlAHMAdAAuAGMAYQBtAGMAbwB0AGUAQABuAG8AdgBvAHQAZQBzAHQALgBjAGEAbABvAGMAYQBsAGgAbwBzAHQADgbcHeX1D8Dq+saY48dGAFVvXh3zWvVzSiDDtTv/vAPWH5sdqkMSRL4r6raCjCOQ", version=4, crand="0b5f113e", cnum="1", response="0100000024A95BA08AA3947964000000"
Content-Length: 0
SIP/2.0 401 Unauthorized
Date: Mon, 03 Feb 2014 20:03:12 GMT
WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="qa121vm179.Novotest.ca", version=4
WWW-Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/qa121vm179.Novotest.ca", version=4
WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="qa121vm179.Novotest.ca", version=4, sts-uri="https://qa121vm179.novotest.ca:443/CertProv/CertProvisioningService.svc"
From: <sip:mcote#novotest.ca>;tag=39539C4FEE9F427D8739BE8E5CD813FB;epid=000C299855EC
To: <sip:mcote#novotest.ca>;tag=FA72F83E7EA12109F5E9C2E8F087DA00
Call-ID: 82C61A739E594A09934681B2A13B1A8D
CSeq: 3 REGISTER
Via: SIP/2.0/TLS 192.168.20.180:5061;ms-received-port=5061;ms-received-cid=164200
ms-diagnostics: 1000;reason="Final handshake failed";HRESULT="0xC3E93EC3(SIP_E_AUTH_UNAUTHORIZED)";source="qa121vm179.Novotest.ca"
Server: RTC/5.0
Content-Length: 0
I tried Indy's SSPI and OverbyteICS's authentication method without success.
Does a way of doing this in delphi exists? If yes, how to do it?
Related
Our outbound calls through Twilio are all being dropped after 32 seconds (inbound calls are fine). The error we receive from Twilio is Error 32022 "Ack not received from your SIP endpoint." I have been going through tutorials and the RFC but I must really be missing something.
The calls are encrypted TLS. SIP ALG has been disabled in our gateway router and our Grandstream PBX is configured for NAT.
Any help is appreciated!
Here is the 200 OK and the ACK that never arrives:
<--- Received SIP response (1177 bytes) from TLS:54.172.60.2:5061 --->
SIP/2.0 200 OK
CSeq: 2218 INVITE
Call-ID: b9e1de31-ce44-4d34-b63b-4c8636e151bf
From: <sip:+13049487110#XXXX>;tag=814fce4e-a1dc-49c7-a917-59496ad182a7
To: <sip:+15132607811#xxxx.pstn.twilio.com>;tag=84858964_c3356d0b_d52c7a82-314f-4be6-88f4-e73110bdbdd8
Via: SIP/2.0/TLS 74.195.14.236:5061;received=74.195.14.236;rport=52191;branch=z9hG4bKPj42ac7abe-f4b7-40dc-a314-8c6a90584481;alias
Record-Route: <sip:54.172.60.2:5060;r2=on;lr;twnat=sip:74.195.14.236:52191>
Record-Route: <sip:54.172.60.2:5061;transport=tls;r2=on;lr;twnat=sip:74.195.14.236:52191>
Server: Twilio
Contact: <sip:172.25.75.195:5060>
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,NOTIFY
Content-Type: application/sdp
X-Twilio-CallSid: CAb39a1e013e6ad6c03bd5bd2827612646
X-Twilio-TlsPolicy: TLSv1.0+
Content-Length: 362
v=0
o=root 1866335776 1866335776 IN IP4 172. ...
<--- Transmitting SIP request (1010 bytes) to TLS:54.172.60.2:5061 --->
ACK sip:54.172.60.2:5061;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 74.195.14.236:5061;rport;branch=z9hG4bKPj483e2dff-e510-4908-89ee-25ec200a4072;alias
From: <sip:+13049487110#XXXX>;tag=814fce4e-a1dc-49c7-a917-59496ad182a7
To: <sip:+15132607811#xxxx.pstn.twilio.com>;tag=84858964_c3356d0b_d52c7a82-314f-4be6-88f4-e73110bdbdd8
Call-ID: b9e1de31-ce44-4d34-b63b-4c8636e151bf
CSeq: 2218 ACK
Route: <sip:54.172.60.2:5061;transport=tls;lr;r2=on;twnat=sip:74.195.14.236:52191>
Route: <sip:54.172.60.2:5060;lr;r2=on;twnat=sip:74.195.14.236:52191>
...
The ACK request s addressed incorrectly: per 3261 with loose routing it should be addressed to the Contact URI, but sent to the topmost Route (built from the bottommost Record-Route, the route-set in your ACK appears to be correct). Correct the request URI for the ACK, that should help.
We are attempting to set up our Pexip Account to make outbound calls to our Twilio account. We successfully have Pexip connecting to Twilio, but are receiving a "407 Proxy Authentication Required". Has anyone successfully been able to have their Pexip account call out to Twilio over SIP?
2021-02-04T14:58:20.140+00:00 pexipconf 2021-02-04 14:58:20,140 Level="INFO" Name="support.sip" Message="Received SIP response" Src-address="XXX.XXX.XXX.XXX" Src-port="5060" Dst-address="10.0.0.11" Dst-port="5060" Transport="UDP" Received-time="2021-02-04T14:58:20,137446" Detail="
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bKf6XLw5U0Ib3YViSKD71cZkM82EoBeQvJ;rport=5060;received=XXX.XXX.XXX.XXX
From: "ROOM1" <sip:meet.room1#10.0.0.11>;tag=vtHb5o3sipqLRM9d;epid=jWcA8h3fGrxnbv26
To: <sip:+XXXXXXXXXX#XXXXX.pstn.twilio.com>
CSeq: 1710901904 INVITE
Call-ID: 3d3600ea-62bb-4252-aae7-8b243c22fb12
Server: Twilio Gateway
Content-Length: 0
"
2021-02-04T14:58:20.150+00:00 pexipconf 2021-02-04 14:58:20,150 Level="INFO" Name="support.sip" Message="Received SIP response" Src-address="XXX.XXX.XXX.XXX" Src-port="5060" Dst-address="10.0.0.11" Dst-port="5060" Transport="UDP" Received-time="2021-02-04T14:58:20,147110" Detail="
SIP/2.0 407 Proxy Authentication required
CSeq: 1710901904 INVITE
Call-ID: 3d3600ea-62bb-4252-aae7-8b243c22fb12
From: "ROOM1" <sip:meet.room1#10.0.0.11>;tag=vtHb5o3sipqLRM9d;epid=jWcA8h3fGrxnbv26
To: <sip:+XXXXXXXXXX#xyvid.pstn.twilio.com>;tag=90026019_6772d868_2f8d0dd6-90f4-42aa-a165-2e00e5964f5a
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bKf6XLw5U0Ib3YViSKD71cZkM82EoBeQvJ;rport=5060
Server: Twilio
Contact: <sip:XXX.XXX.XXX.XXX:5060>
Proxy-Authenticate: Digest realm="sip.twilio.com",qop="auth",nonce="mac-Uxca9fW-9FggC2z8lZSbd2KgmidgS66hPf-NStrNhtY1",opaque="b90d5a4f4492449aecc8caf7bc58e864"
Content-Length: 0
"
2021-02-04T14:58:20.153+00:00 pexipconf 2021-02-04 14:58:20,152 Level="INFO" Name="support.sip" Message="Sending SIP request" Src-address="10.0.0.11" Src-port="5060" Dst-address="XXX.XXX.XXX.XXX" Dst-port="5060" Transport="UDP" Detail="
ACK sip:+XXXXXXXXXX#xyvid.pstn.twilio.com SIP/2.0
From: "ROOM1" <sip:meet.room1#10.0.0.11>;tag=vtHb5o3sipqLRM9d;epid=jWcA8h3fGrxnbv26
Call-ID: 3d3600ea-62bb-4252-aae7-8b243c22fb12
To: <sip:+XXXXXXXXXX#xyvid.pstn.twilio.com>;tag=90026019_6772d868_2f8d0dd6-90f4-42aa-a165-2e00e5964f5a
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;branch=z9hG4bKf6XLw5U0Ib3YViSKD71cZkM82EoBeQvJ;rport
CSeq: 1710901904 ACK
Content-Length: 0
"
Phone numbers and IP addresses changed to protect the innocent.
We do have our Pexip IP address listed in the IP ACL of our Twilio account.
Did you defined a Credential List on your Elastic SIP Trunk? The 407 Proxy Authentication required is asking your SIP User Agent to respond back with its authentication credentials (username and password).
i am using FreeSWITCH server and integrated with twilio SIP turnk. i am using android imsdroid application for making sip calls. imsdroid to imsdroid call is happening. imsdroid to PSTN no (i.e mobile number) call is not working. Gateway timeout error is shown in imsdroid. INVITE is sent to FreeSWITCH and freeswitch server is routing the call to Twilio. But not receiving any response. What could be the issue.
IP is allowed.From SIPML5 client to PSTN call is working. Below is the INVITE that is going from FreeSWITCH
INVITE sip:+919986790176#nowconf.pstn.twilio.com SIP/2.0
Via: SIP/2.0/UDP 220.227.38.107:5080;rport;branch=z9hG4bK5yt865UUKDF4H
Max-Forwards: 69
From: "+919845217138" <sip:FreeSWITCH#nowconf.pstn.twilio.com>;tag=eFNKtBae4HN1r
To: <sip:+919986790176#nowconf.pstn.twilio.com>
Call-ID: 06f7df5f-1f81-1235-67b0-2e81eca04f81
CSeq: 98923179 INVITE
Contact: <sip:gw+Twilio-outbound#220.227.38.107:5080;transport=udp;gw=Twilio-outbound>
User-Agent: FreeSWITCH-mod_sofia/1.6.10+git~20160824T215404Z~726448d962~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 248
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
P-Access-Network-Info: ADSL;utran-cell-id-3gpp=00000000
X-FS-Support: update_display,send_info
Remote-Party-ID: "+919845217138" <sip:+919845217138#nowconf.pstn.twilio.com>;party=calling;screen=yes;privacy=off
v=0
o=FreeSWITCH 1478495490 1478495491 IN IP4 220.227.38.107
s=FreeSWITCH
c=IN IP4 220.227.38.107
t=0 0
m=audio 22996 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
SIPML5 INVITE
INVITE sip:+919742164769#nowconf.pstn.twilio.com SIP/2.0
Via: SIP/2.0/UDP 220.227.38.107:5080;rport;branch=z9hG4bKD5jv3tcpNtFDS
Max-Forwards: 69
From: "+919845217138" <sip:FreeSWITCH#nowconf.pstn.twilio.com>;tag=cvS8XKDp62Z5e
To: <sip:+919742164769#nowconf.pstn.twilio.com>
Call-ID: 69171aa5-1d0d-1235-67b0-2e81eca04f81
CSeq: 98788399 INVITE
Contact: <sip:gw+Twilio-outbound#220.227.38.107:5080;transport=udp;gw=Twilio-outbound>
User-Agent: FreeSWITCH-mod_sofia/1.6.10+git~20160824T215404Z~726448d962~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 488
X-FS-Support: update_display,send_info
Remote-Party-ID: "+919845217138" <sip:+919845217138#nowconf.pstn.twilio.com>;party=calling;screen=yes;privacy=off
v=0
o=FreeSWITCH 1478224523 1478224524 IN IP4 220.227.38.107
s=FreeSWITCH
c=IN IP4 220.227.38.107
t=0 0
m=audio 24404 RTP/AVP 102 9 0 8 103 101
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=0; cbr=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40; stereo=1
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 telephone-event/48000
a=fmtp:103 0-16
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
ACK sip:172.18.22.113:5060 SIP/2.0
Via: SIP/2.0/UDP 220.227.38.107:5080;rport;branch=z9hG4bKeecN5NXSj35Zm
Route: <sip:54.172.60.3:5060;lr;ftag=cvS8XKDp62Z5e>
Max-Forwards: 70
From: "+919845217138" <sip:FreeSWITCH#nowconf.pstn.twilio.com>;tag=cvS8XKDp62Z5e
To: <sip:+919742164769#nowconf.pstn.twilio.com>;tag=70832428_6772d868_27e46324-e125-4895-a6ff-98031cdb43fc
Call-ID: 69171aa5-1d0d-1235-67b0-2e81eca04f81
CSeq: 98788399 ACK
Contact: <sip:gw+Twilio-outbound#220.227.38.107:5080;transport=udp;gw=Twilio-outbound>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 54.172.60.3:5060;branch=z9hG4bK763a.52f422d4.0
Via: SIP/2.0/UDP 172.18.22.113:5060;rport=5060;received=54.172.61.235;branch=z9hG4bK27e46324-e125-4895-a6ff-98031cdb43fc_6772d868_294770755291215
From: <sip:+919742164769#nowconf.pstn.twilio.com>;tag=70832428_6772d868_27e46324-e125-4895-a6ff-98031cdb43fc
To: "+919845217138" <sip:FreeSWITCH#nowconf.pstn.twilio.com>;tag=cvS8XKDp62Z5e
Call-ID: 69171aa5-1d0d-1235-67b0-2e81eca04f81
CSeq: 1 BYE
User-Agent: FreeSWITCH-mod_sofia/1.6.10+git~20160824T215404Z~726448d962~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Content-Length: 0
Please remove these two headers before sending to Twilio:
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
P-Access-Network-Info: ADSL;utran-cell-id-3gpp=00000000
To do so you have to write these two line before sending call to Twilio sip gateway:
<action application="unset" data="sip_h_P-Preferred-Service"/>
<action application="unset" data="sip_h_P-Access-Network-Info"/>
I implemented the outlook REST api on my Rails app following this official tutorial: https://dev.outlook.com/restapi/tutorial/ruby
By the way, it needs to be updated. Outlook now requires more permissions ('profile') to get the email of the user in the auth controller:
SCOPES = [ 'openid', 'profile', 'https://outlook.office.com/mail.read' ]
Anyhow, I am storing the email and token after authenticating, but that token is very short lived. I need a way to permanently store authentication for the user.
When I run things as suggested and want to get the emails the response is:
...
response_headers: !ruby/hash-with-ivars:Faraday::Utils::Headers
elements:
content-length: '0'
server: Microsoft-IIS/8.5
set-cookie: exchangecookie=afaeef5a8a6747aab24dad1ddb97a8fb; expires=Fri, 16-Jun-2017
00:07:54 GMT; path=/; HttpOnly
www-authenticate: Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000#*",
token_types="app_asserted_user_v1 service_asserted_app_v1", authorization_uri="https://login.windows.net/common/oauth2/authorize",
error="invalid_token",Basic Realm="",Basic Realm=""
request-id: c59488ab-62b5-4a9f-a3f5-43bda739c9ab
x-calculatedbetarget: BLUPR07MB260.namprd07.prod.outlook.com
x-backendhttpstatus: '401'
x-ms-diagnostics: '2000010;reason="ErrorCode: ''PP_E_RPS_REASON_TIMEWINDOW_EXPIRED''.
Message: ''Failed the Validate call, reason: Time window expired.%0d%0a''";error_category="invalid_msa_ticket"'
x-diaginfo: BLUPR07MB260
x-beserver: BLUPR07MB260
x-powered-by: ASP.NET
x-feserver: BN3PR16CA0057
x-msedge-ref: 'Ref A: 3E2E02429DE244F7A738A7BE6CF9E06B Ref B: CAA6321D024D5B725BA8FFE7DAC85411
Ref C: Wed Jun 15 17:07:54 2016 PST'
date: Thu, 16 Jun 2016 00:07:54 GMT
connection: close
ivars:
:#names:
content-length: content-length
server: server
set-cookie: set-cookie
www-authenticate: www-authenticate
request-id: request-id
x-calculatedbetarget: x-calculatedbetarget
x-backendhttpstatus: x-backendhttpstatus
x-ms-diagnostics: x-ms-diagnostics
x-diaginfo: x-diaginfo
x-beserver: x-beserver
x-powered-by: x-powered-by
x-feserver: x-feserver
x-msedge-ref: x-msedge-ref
date: date
connection: connection
status: 401
How do I adjust this code to store a permanent token?
OK< I found a few answers on StackOverflow for different stacks. I would normally delete my post, but for Rails developer who may need this, the answer to my questions is simply adding 'offline_access' to SCOPES = [ 'openid', 'profile', 'offline_access', 'https://outlook.office.com/mail.read' ]
I have network IP camera(Canon VB-M40). This camera support ONVIF protocol. I am implementing its ONVIF functionality in windows using C language. I got its RTSP URI using following request.
snprintf(postData, sizeof(postData),
"<?xml version=\"1.0\" encoding=\"utf-8\"?>"
"<soap:Envelope xmlns:soap=\"http://www.w3.org/2003/05/soap-envelope\" "
"xmlns:tds=\"http://www.onvif.org/ver10/media/wsdl\""
"xmlns:tt=\"http://www.onvif.org/ver10/schema\">"
"<soap:Body>"
"<tds:GetStreamUri>"
"<tds:StreamSetup>"
"<tt:Stream>0</tt:Stream>"
"<tt:Transport>"
"<tt:Protocol>HTTP</tt:Protocol>"
"</tt:Transport>"
"</tds:StreamSetup>"
"<tds:ProfileToken>profile1</tds:ProfileToken>"
"</tds:GetStreamUri>"
"</soap:Body></soap:Envelope>",
username, digest_str, nonce_str, time_str);
and the response is:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsa5="http://www.w3.org/2005/08/addressing"
xmlns:c14n="http://www.w3.org/2001/10/xml-exc-c14n#"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:MC2="http://www.onvif.org/ver10/schema"
xmlns:MC3="http://www.w3.org/2005/05/xmlmime"
xmlns:MC4="http://docs.oasis-open.org/wsn/b-2"
xmlns:MC10="http://www.w3.org/2004/08/xop/include"
xmlns:MC5="http://docs.oasis-open.org/wsrf/bf-2"
xmlns:MC6="http://docs.oasis-open.org/wsn/t-1"
xmlns:CC="http://www.canon.com/ns/networkcamera/onvif/va/schema"
xmlns:MC1="http://www.onvif.org/ver10/media/wsdl"
xmlns:MC8="http://www.onvif.org/ver20/analytics/wsdl/RuleEngineBinding"
xmlns:MC9="http://www.onvif.org/ver20/analytics/wsdl/AnalyticsEngineBinding"
xmlns:MC7="http://www.onvif.org/ver20/analytics/wsdl"
xmlns:ter="http://www.onvif.org/ver10/error"
xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"
xmlns:tns1="http://www.onvif.org/ver10/topics">
<SOAP-ENV:Header></SOAP-ENV:Header>
<SOAP-ENV:Body>
<MC1:GetStreamUriResponse>
<MC1:MediaUri>
<MC2:Uri>rtsp://192.168.5.53:8090/profile1=r</MC2:Uri>
<MC2:InvalidAfterConnect>false</MC2:InvalidAfterConnect>
<MC2:InvalidAfterReboot>true</MC2:InvalidAfterReboot>
<MC2:Timeout>PT0M0S</MC2:Timeout>
</MC1:MediaUri>
</MC1:GetStreamUriResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
according to ONVIF specification, once I get the stream URI I should send 'DESCRIBE' request to the device. I am using this procedure because I need stream on TCP.
My question is how to send 'DESCRIBE' request to the Device and on which socket?
Should I send this request on the same socket on which I sent GetStreamURI request. Or I have to create an other one. And what will be the format of the request?
Send it to the same host as GetStreamUri request on port 554 (or other port configured in the device for RTSP). Then you have to send OPTIONS request before DESCRIBE. It will probably return 401 Unauthorized status and nonce + realm value in its body. (I am using diferent address then you recieved in your GetStreamUri response.)
Request:
OPTIONS http://192.168.128.99:80/profile1/media.smp RTSP/1.0\r\n
CSeq: 1\r\n
User-Agent: MyAgent\r\n\r\n
Response:
RTSP/1.0 401 Unauthorized
CSeq: 1
Date: Thu Jun 28 05:39:55 2012 GMT
Expires: Thu Jun 28 05:39:55 2012 GMT
Cache-Control: must-revalidate
WWW-Authenticate: Digest realm="iPOLiS", nonce="00000000000000000000000048E02F14"
Read this realm and nonce values, because you need it for autorization and send another, authorized OPTIONS request.
OPTIONS http://192.168.128.99:80/profile1/media.smp RTSP/1.0\r\n
CSeq: 2\r\n
Authorization: Digest username="admin", realm="iPOLiS", nonce="00000000000000000000000048E02F14", uri="http://192.168.128.99:80/profile1/media.smp", response="23a5a81fb98b6cb29368eba060ba31b9"\r\n
User-Agent: MyAgent\r\n\r\n
Response is generate this way
Then come DESCRIBE request
DESCRIBE http://192.168.128.99:80/profile1/media.smp RTSP/1.0\r\n
CSeq: 3\r\n
User-Agent: MyAgent\r\n\r\n
and response
RTSP/1.0 200 OK
CSeq: 3
Date: Thu Jun 28 05:46:20 2012 GMT
Expires: Thu Jun 28 05:46:20 2012 GMT
Content-Base: http://192.168.128.99:554/profile1/media.smp/
Content-Type: application/sdp
Content-Length: 498
x-Accept-Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Cache-Control: must-revalidate
v=0
o=- 0 0 IN IP4 192.168.128.9
s=Media Presentation
i=samsung
c=IN IP4 0.0.0.0
b=AS:384128
t=0 0
a=control:http://192.168.128.99:554/profile1/media.smp
a=range:npt=now-
m=video 40336 RTP/AVP 26
b=AS:384000
a=rtpmap:26 JPEG/90000
a=control:http://192.168.128.99:554/profile1/media.smp/trackID=v
a=cliprect:0,0,768,1024
a=framesize:26 1024-768
a=framerate:5.0
m=audio 40338 RTP/AVP 0
b=AS:64
a=rtpmap:0 PCMU/8000
a=control:http://192.168.128.99:554/profile1/media.smp/trackID=a
from this response address in a=control:http://192.168.128.99:554/profile1/media.smp/trackID=v should be parsed for media m=video (its a SDP protocol). Thats how far did i get. Next procedure should be to make SETUP request with transport information and then send PLAY request. You must listen on the port you specified in SETUP request to recieve images.