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"/>
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'm trying to get SRTP going in my iOS application using PJSIP. I have TLS working and without SRTP I can make and receive calls. However with SRTP I'm getting this odd 488 error on the INVITE. It's not able to initialize the media.
I've read other articles mentioning about the codecs. But I've insured that the codes being used by my Asterisk server and those compiled with PJSIP library on my iOS app are the same. The only thing I'm seeing here is that I'm enabled the crypto and PJSIP isn't liking it. Any thoughts?
INVITE sip:[REDACTED]#[REDACTED]:47229;transport=TLS;ob SIP/2.0
Via: SIP/2.0/TLS [REDACTED]:5161;rport;branch=z9hG4bKPj8ea1a332-0748-438f-ae74-5d17b038891d;alias
From: "Test" <sip:asterisk#172.31.18.138>;tag=7c3663cb-b5f5-4762-8526-8425d18b2466
To: <sip:[REDACTED]#[REDACTED];ob>
Contact: <sip:asterisk#[REDACTED]:5161;transport=TLS>
Call-ID: f454ef36-01ea-4f29-9482-4a10768bf1b7
CSeq: 24942 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, path
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-AsteriskNOW-13.0.190.12(13.13.1)
Content-Type: application/sdp
Content-Length: 398
v=0
o=- 1582453973 1582453973 IN IP4 172.31.18.138
s=Asterisk
c=IN IP4 [REDACTED]
t=0 0
m=audio 11410 RTP/AVP 3 110 9 97 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:84m7hqGvMjTU21xzkhBS3RQpQQjJ+aep0VwSlhx+
a=rtpmap:3 GSM/8000
a=rtpmap:110 speex/8000
a=rtpmap:9 G722/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:60
a=sendrecv
--end msg--
19:10:11.601 pjsua_call.c .Incoming Request msg INVITE/cseq=24942 (rdata0x1421f0540)
19:10:11.603 tsx0x1421fe0a8 ...Transaction created for Request msg INVITE/cseq=24942 (rdata0x1421f0540)
19:10:11.603 tsx0x1421fe0a8 ..Incoming Request msg INVITE/cseq=24942 (rdata0x1421f0540) in state Null
19:10:11.603 tsx0x1421fe0a8 ...State changed from Null to Trying, event=RX_MSG
19:10:11.603 dlg0x1421fd8a8 ....Transaction tsx0x1421fe0a8 state changed to Trying
19:10:11.603 dlg0x1421fd8a8 ..UAS dialog created
19:10:11.603 dlg0x1421fd8a8 ..Module mod-invite added as dialog usage, data=0x141de7588
19:10:11.603 dlg0x1421fd8a8 ...Session count inc to 3 by mod-invite
19:10:11.603 inv0x1421fd8a8 ..UAS invite session created for dialog dlg0x1421fd8a8
19:10:11.603 dlg0x1421fd8a8 ...Session count inc to 3 by mod-pjsua
19:10:11.603 pjsua_media.c ..Call 0: initializing media..
19:10:11.603 pjsua_call.c ..Error initializing media channel: Not Acceptable Here [status=170488]
19:10:11.604 endpoint ..Response msg 488/INVITE/cseq=24942 (tdta0x1421fe800) created
19:10:11.604 dlg0x1421fd8a8 ...Sending Response msg 488/INVITE/cseq=24942 (tdta0x1421fe800)
19:10:11.606 tsx0x1421fe0a8 ...Sending Response msg 488/INVITE/cseq=24942 (tdta0x1421fe800) in state Trying
19:10:11.606 pjsua_core.c ....TX 429 bytes Response msg 488/INVITE/cseq=24942 (tdta0x1421fe800) to TLS [REDACTED]:5161:
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/TLS [REDACTED]:5161;rport=5161;received=[REDACTED];branch=z9hG4bKPj8ea1a332-0748-438f-ae74-5d17b038891d;alias
Call-ID: f454ef36-01ea-4f29-9482-4a10768bf1b7
From: "Test" <sip:asterisk#172.31.18.138>;tag=7c3663cb-b5f5-4762-8526-8425d18b2466
To: <sip:[REDACTED]#[REDACTED];ob>;tag=5oFGceZO4ZaKpLFEg7piOrM7IV2yeDLT
CSeq: 24942 INVITE
Content-Length: 0
--end msg--
In case anyone else has this issue. I'll tell you what solved this for me.
On Asterisk in my endpoint (pjsip show endpoint myendpoint) setting I had media_encryption_optimistic set to true. When I set this to false everything started working.
I'm not sure why as the how to on asterisk stated to turn this on. But I confirmed at all traffic was indeed encrypted by using wireshark to check the actual voice data.
If anyone know why this would be the case that this needed to be set to false it would help me better understand this. But for now I'm up and running.
I had this error on PJSIP ios and I solved on my end after DISABLING "SRTP" or "S-RTP" or "Secure RTP" or "Secure Transport". I removed this for TLS configuration.
//acc_cfg.srtp_secure_signaling = 1;
//acc_cfg.use_srtp = PJMEDIA_SRTP_MANDATORY;
488 / Not Acceptable Here
I also get the same problem with my server, atlast i find the solution
by getting to know that it is because codec, use right codec or
disable codec works great for you.
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?
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.