Format of properly formed 200 ACK response in VOIP communications - twilio

We have a Grandstream UCM6204 PBX connecting to a registered SIP elastic trunk through Twilio. Our trunk originating calls drop after about 60 seconds. Twilio is blaming Grandstream but Grandstream is blaming Twilio. Each is saying the other is not properly formatting or not reading the packet correctly. Pcap log with single 200 ACK packet in question exported.
According to Twilio, the packet should have an acknowledge something like this:
ACK sip:172.18.23.153:5060 SIP/2.0
Grandstream says they (their unit) won't send it to the private IP address and should be sent to the record-route IP address where it will be forwarded to the private IP based on header info. I'm too much of a newbie here to know what's right and what's wrong so any suggestions would be great.
No. Time Source Destination Protocol Length Info
3 0.119432 96.10.11.12 54.172.60.2 SIP/SDP 1217 Status: 200 OK |
Frame 3: 1217 bytes on wire (9736 bits), 1217 bytes captured (9736 bits)
Encapsulation type: Linux cooked-mode capture (25)
Arrival Time: Dec 19, 2018 13:51:32.749232000 Eastern Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1545245492.749232000 seconds
[Time delta from previous captured frame: 0.050481000 seconds]
[Time delta from previous displayed frame: 0.050481000 seconds]
[Time since reference or first frame: 0.119432000 seconds]
Frame Number: 3
Frame Length: 1217 bytes (9736 bits)
Capture Length: 1217 bytes (9736 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: sll:ethertype:ip:udp:sip:sdp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Linux cooked capture
Packet type: Unicast to us (0)
Link-layer address type: 1
Link-layer address length: 6
Source: 0e:d7:c3:5c:55:24 (0e:d7:c3:5c:55:24)
Unused: 0000
Protocol: IPv4 (0x0800)
Internet Protocol Version 4, Src: 96.10.11.12, Dst: 54.172.60.2
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 1201
Identification: 0x0000 (0)
Flags: 0x4000, Don't fragment
0... .... .... .... = Reserved bit: Not set
.1.. .... .... .... = Don't fragment: Set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 39
Protocol: UDP (17)
Header checksum: 0x3257 [validation disabled]
[Header checksum status: Unverified]
Source: 96.10.11.12
Destination: 54.172.60.2
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Source Port: 5060
Destination Port: 5060
Length: 1181
Checksum: 0xfa57 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 1]
[Response Time (ms): 119]
Message Header
Via: SIP/2.0/UDP 54.172.60.2:5060;rport=5060;received=54.172.60.2;branch=z9hG4bK0d03.870e90c7.0
Transport: UDP
Sent-by Address: 54.172.60.2
Sent-by port: 5060
RPort: 5060
Received: 54.172.60.2
Branch: z9hG4bK0d03.870e90c7.0
Via: SIP/2.0/UDP 172.18.15.132:5060;rport=5060;received=172.18.15.132;branch=z9hG4bK5d21b0af-3104-4e32-96a7-7e89edd39a93_6772d868_310-9499633517006747707
Transport: UDP
Sent-by Address: 172.18.15.132
Sent-by port: 5060
RPort: 5060
Received: 172.18.15.132
Branch: z9hG4bK5d21b0af-3104-4e32-96a7-7e89edd39a93_6772d868_310-9499633517006747707
Record-Route: <sip:54.172.60.2:5060;lr;ftag=90419967_6772d868_5d21b0af-3104-4e32-96a7-7e89edd39a93>
Record-Route URI: sip:54.172.60.2:5060;lr;ftag=90419967_6772d868_5d21b0af-3104-4e32-96a7-7e89edd39a93
Record-Route Host Part: 54.172.60.2
Record-Route Host Port: 5060
Record-Route URI parameter: lr
Record-Route URI parameter: ftag=90419967_6772d868_5d21b0af-3104-4e32-96a7-7e89edd39a93
Call-ID: 937861cfda42d874af27d391663108b1#0.0.0.0
From: <sip:+12485551212#somebody.pstn.twilio.com>;tag=90419967_6772d868_5d21b0af-3104-4e32-96a7-7e89edd39a93
SIP from address: sip:+12485551212#somebody.pstn.twilio.com
SIP from address User Part: +12485551212
E.164 number (MSISDN): 12485551212
Country Code: Americas (1)
SIP from address Host Part: somebody.pstn.twilio.com
SIP from tag: 90419967_6772d868_5d21b0af-3104-4e32-96a7-7e89edd39a93
To: <sip:+12486661212#96.10.11.12>;tag=68625bc3-5cb5-4bd4-a255-ce12744a3514
SIP to address: sip:+12486661212#96.10.11.12
SIP to address User Part: +12486661212
E.164 number (MSISDN): 12486661212
Country Code: Americas (1)
SIP to address Host Part: 96.10.11.12
SIP to tag: 68625bc3-5cb5-4bd4-a255-ce12744a3514
CSeq: 28344 INVITE
Sequence Number: 28344
Method: INVITE
Server: Grandstream UCM6204V1.5A 1.0.18.12
Contact: <sip:+12485551212#192.168.4.10:5060>
Contact URI: sip:+12485551212#192.168.4.10:5060
Contact URI User Part: +12485551212
E.164 number (MSISDN): 12485551212
Country Code: Americas (1)
Contact URI Host Part: 192.168.4.10
Contact URI Host Port: 5060
Allow: OPTIONS, INFO, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE, REGISTER
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 237
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 1796373137 1796373139 IN IP4 192.168.4.10
Owner Username: -
Session ID: 1796373137
Session Version: 1796373139
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 192.168.4.10
Session Name (s): Asterisk
Connection Information (c): IN IP4 192.168.4.10
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 192.168.4.10
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 13894 RTP/AVP 0 101
Media Type: audio
Media Port: 13894
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMU
Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute Fieldname: rtpmap
Media Format: 0
MIME Type: PCMU
Sample Rate: 8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
Media Attribute (a): ptime:20
Media Attribute Fieldname: ptime
Media Attribute Value: 20
Media Attribute (a): maxptime:150
Media Attribute Fieldname: maxptime
Media Attribute Value: 150
Media Attribute (a): sendrecv

Related

Why is the SIP ACK sent from our PBX not received by Twilio?

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.

django channels can not output logs in real time

my code:
def ws_receive(message):
text = message.content['text']
request = json.loads(text)
cmd = request['cmd']
results = run(cmd)
print(cmd)
for result in results:
Group(GROUP_NAME).send({'text':result.decode('utf-8')})
print(result)
cmd is like ping -c 4 www.google.com;
the terminal results is:
[2017/09/24 07:24:44] WebSocket HANDSHAKING / [127.0.0.1:59285]
[2017/09/24 07:24:44] WebSocket CONNECT / [127.0.0.1:59285]
[2017/09/24 07:24:44] HTTP GET /api/hosts/?status=used 200 [0.07, 127.0.0.1:59247]
ping -c 4 www.google.com
2017-09-24 07:24:58.512885 b'PING www.google.com (74.125.23.103): 56 data bytes\n'
2017-09-24 07:24:58.513127 b'64 bytes from 74.125.23.103: icmp_seq=0 ttl=45 time=138.542 ms\n'
2017-09-24 07:24:59.517881 b'64 bytes from 74.125.23.103: icmp_seq=1 ttl=45 time=142.954 ms\n'
2017-09-24 07:25:00.522698 b'64 bytes from 74.125.23.103: icmp_seq=2 ttl=45 time=144.568 ms\n'
2017-09-24 07:25:01.562285 b'64 bytes from 74.125.23.103: icmp_seq=3 ttl=45 time=180.163 ms\n'
2017-09-24 07:25:01.562400 b'\n'
2017-09-24 07:25:01.562459 b'--- www.google.com ping statistics ---\n'
2017-09-24 07:25:01.562517 b'4 packets transmitted, 4 packets received, 0.0% packet loss\n'
2017-09-24 07:25:01.562586 b'round-trip min/avg/max/stddev = 138.542/151.557/180.163/16.662 ms\n'
but,The browser's websocket debugging information is:
so, I‘am sure the channels is execute the command until the end sent the message,but i want real-time send the message.
Try sending immediately:
Group(GROUP_NAME).send({'text':result.decode('utf-8')}, immediately=True)
The reason behind this is that you are inside the websocket consumer function. While you are inside it, the Group.send calls are not executed, but only collected and executed in batch once you leave the function. Using immediately=True overrides this behaviour.

SRTP Issue : PJSIP Error initializing media channel: Not Acceptable Here [status=170488]

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.

<ask> acces-reject on freeradius

i just installed freeradius 1.1.7 from tarbal.
Actually i don't get any error in compile and installation process.
first,when i try to running on debug mode everything looked running well
stantiated acct_unique (acct_unique)
Module: Loaded detail
detail: detailfile = "/usr/local/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d"
detail: detailperm = 384
detail: dirperm = 493
detail: locking = no
Module: Instantiated detail (detail)
Module: Loaded radutmp
radutmp: filename = "/usr/local/var/log/radius/radutmp"
radutmp: username = "%{User-Name}"
radutmp: case_sensitive = yes
radutmp: check_with_nas = yes
radutmp: perm = 384
radutmp: callerid = yes
Module: Instantiated radutmp (radutmp)
Listening on authentication *:1812
Listening on accounting *:1813
Ready to process requests.
Then i try to test user with following command, but i got reject packet from freeradius
radtest user 1111 127.0.0.1 1812 testing123
Sending Access-Request of id 19 to 127.0.0.1 port 1812
User-Name = "user"
User-Password = "1111"
NAS-IP-Address = 255.255.255.255
NAS-Port = 1812
rad_recv: Access-Reject packet from host 127.0.0.1:1812, id=19, length=20
on debug mode i got message like bellow :
rad_recv: Access-Request packet from host 127.0.0.1:50886, id=90, length=56
User-Name = "user"
User-Password = "1111"
NAS-IP-Address = 255.255.255.255
NAS-Port = 1812
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
modcall[authorize]: module "preprocess" returns ok for request 0
modcall[authorize]: module "chap" returns noop for request 0
modcall[authorize]: module "mschap" returns noop for request 0
rlm_realm: No '#' in User-Name = "user", looking up realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 0
rlm_eap: No EAP-Message, not doing EAP
modcall[authorize]: module "eap" returns noop for request 0
users: Matched entry DEFAULT at line 153
modcall[authorize]: module "files" returns ok for request 0
radius_xlat: 'user'
rlm_sql (sql): sql_set_user escaped user --> 'user'
radius_xlat: 'SELECT id, UserName, Attribute, Value, op FROM radcheck WHERE Username = 'user' ORDER BY id'
rlm_sql (sql): Reserving sql socket id: 4
radius_xlat: 'SELECT radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op FROM radgroupcheck,usergroup WHERE usergroup.Username = 'user' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id'
rlm_sql_mysql: MYSQL check_error: 1146 received
rlm_sql_getvpdata: database query error
radius_xlat: 'SELECT id, UserName, Attribute, Value, op FROM radreply WHERE Username = 'user' ORDER BY id'
radius_xlat: 'SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = 'user' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id'
rlm_sql_mysql: MYSQL check_error: 1146 received
rlm_sql_getvpdata: database query error
rlm_sql (sql): Released sql socket id: 4
modcall[authorize]: module "sql" returns ok for request 0
rlm_pap: Found existing Auth-Type, not changing it.
modcall[authorize]: module "pap" returns noop for request 0
modcall: leaving group authorize (returns ok) for request 0
rad_check_password: Found Auth-Type System
auth: type "System"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 0
modcall[authenticate]: module "unix" returns notfound for request 0
modcall: leaving group authenticate (returns notfound) for request 0
auth: Failed to validate the user.
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Sending Access-Reject of id 90 to 127.0.0.1 port 50886
Waking up in 4 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 90 with timestamp 5130196a
Nothing to do. Sleeping until we see a request.
what should i do to solve this problem ?
Thanks
May be you should check your clients.conf file.
I think you didn't mention 127.0.0.1 as ipaddr in client localhost{}.

Get live stream from Network IP camera that support ONVIF protocol?

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.

Resources