sip door entry system to sip call fails

barry florence · ‎01-14-2015

call manager 10.5.1.10000-7

(2N Helios IP ) door system(2042)-> cucm->DX650(3513)

Time stamp:16:23:27

Hi

when call initiated from door system to user (DX650), it rings, once answered on the phone it disconnects the call and gives fast busy tone instead of connecting the call. Same calls work in jabber and also in sccp phones. I have attached the call manager trace, please help on this.

Thanks

Barry

Brandon Pierce · ‎01-14-2015

16:23:30.128
[938093,NET]
SIP/2.0 487 Request Cancelled
Via: SIP/2.0/TCP 10.1.3.5:5060;branch=z9hG4bK561357876724
From: <sip:2042@10.1.3.5>;tag=302168~23001403-1e76-4ea5-8dd4-52d6f82b946c-27747696
To: <sip:3513@10.1.3.5>;tag=a0481c95c0c8011a00004c29-000068b9
Call-ID: aa0caf00-4b6197ff-298d-503010a@10.1.3.5
Date: Wed, 14 Jan 2015 16:23:49 GMT
CSeq: 101 INVITE
Server: Cisco-CSF
Contact: <sip:0bed8813-62a5-6dcf-6e3d-90cc088a245d@10.0.0.74:63931;transport=tcp>;video;bfcp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "Navjot Mary" <sip:3513@10.1.3.5>;party=called;id-type=subscriber;privacy=off;screen=yes
Allow-Events: kpml,dialog
Content-Length: 0

Your call is being cut down with normal call clearing. Why are both endpoints listed with the same IP addresses....Yet on the initial INVITE you got:

6:23:27.808
Incoming SIP UDP message size 984 from 10.1.4.93:[5060]:
[938068,NET]
INVITE sip:3513@10.1.3.5 SIP/2.0
Via: SIP/2.0/UDP 10.1.4.93:5060;rport;branch=z9hG4bK15784
From: "Front Door" <sip:2042@10.1.3.5>;tag=28231
To: <sip:3513@10.1.3.5>
Call-ID: 744
CSeq: 20 INVITE
Contact: <sip:2042@10.1.4.93:5060>
Content-Type: application/sdp
Allow: REGISTER, INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, NOTIFY, PRACK
Max-Forwards: 70
User-Agent: 2N Helios IP Vario 2.6.0.13.7
Supported: 100rel
Content-Length: 540

v=0
o=- 1218278268 1162695338 IN IP4 10.1.4.93
s=HIP 2.6.0.13.7
t=0 0
m=audio 5000 RTP/AVP 0 8 101
c=IN IP4 10.1.4.93
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
m=video 5002 RTP/AVP 123 124 98 34
c=IN IP4 10.1.4.93
a=sendonly
a=rtpmap:123 H264/90000
a=fmtp:123 profile-level-id=42801E; packetization-mode=1
a=rtpmap:124 H264/90000
a=fmtp:124 profile-level-id=42801E; packetization-mode=0
a=rtpmap:98 H263-1998/90000
a=fmtp:98 QCIF=1; CIF=1
a=rtpmap:34 H263/90000
a=fmtp:34 QCIF=1; CIF=1

16:23:30.094
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.4.93:5060;rport;branch=z9hG4bK15784
From: "Front Door" <sip:2042@10.1.3.5>;tag=28231
To: <sip:3513@10.1.3.5>;tag=302166~23001403-1e76-4ea5-8dd4-52d6f82b946c-27747695

.....

....

.....

You got some SIP crazyness going on here that you need to clean up. SDP ends up choosing the appropriate media from what I can see. What is the overall flow of this system?

barry florence · ‎01-14-2015

Hi Brandon,

(2N Helios IP --10.1.4.93-2042) door system-> cucm(10.1.3.5)->DX650(3513-10.1.4.49-receptionphone)

Thanks for the reply, both the devices are registered to the same call manager(10.1.3.5) on the same site, thats reason it is showing the same ip address.

Thanks

Barry

Brandon Pierce · ‎01-14-2015

Ok, was unaware of your topology setup. That still doesn't explain the tear down of the call. What do the logs from the perspective of the Helios say if there are any?

barry florence · ‎01-14-2015

They gave up, as it is working with other phones, they expect to work on this one as well.

Thanks

Brandon Pierce · ‎01-14-2015

I know you said they gave up but I took a second whack at it. I see that you send out the initial SDP in the first INVITE but when CUCM gets it to pass it on to the DX650 there is no SDP for some reason. Are you using delayed offer or early offer? Finally, the DX650 comes back and offers everything back to the Helios.

v=0
o=Cisco-SIPUA 1129 0 IN IP4 10.1.4.49
s=SIP Call
t=0 0
m=audio 18126 RTP/AVP 0 8 18 102 116 101
c=IN IP4 10.1.4.49
a=trafficclass:conversational.audio.avconf.aq:admitted
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:102 L16/16000
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 27814 RTP/AVP 100 112 126 97
c=IN IP4 10.1.4.49
b=TIAS:4000000
a=trafficclass:conversational.video.avconf.aq:admitted
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=640028;packetization-mode=1;level-asymmetry-allowed=1;max-fps=6000;max-rcmd-nalu-size=256000
a=imageattr:* recv [x=1024,y=600,q=0.60] [x=1280,y=720,q=0.50]
a=rtpmap:112 H264/90000
a=fmtp:112 profile-level-id=4D0028;packetization-mode=1;level-asymmetry-allowed=1;max-fps=6000;max-rcmd-nalu-size=256000
a=imageattr:* recv [x=1024,y=600,q=0.60] [x=1280,y=720,q=0.50]
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=428028;packetization-mode=1;level-asymmetry-allowed=1;max-fps=6000;max-rcmd-nalu-size=256000
a=imageattr:* recv [x=1024,y=600,q=0.60] [x=1280,y=720,q=0.50]
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=428028;packetization-mode=0;level-asymmetry-allowed=1;max-fps=6000;max-rcmd-nalu-size=256000
a=imageattr:* recv [x=1024,y=600,q=0.60] [x=1280,y=720,q=0.50]
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=sendrecv

You then get a CANCEL proceeded by an ACK with negotiated SDP but it's to late.

barry florence · ‎01-14-2015

Thanks for the reply. It looks based on the traces i can see it is using early offer between the Helios IP and CUCM, inbetween it uses delayed offer between CUCM and DX650 as in the previous attached callchart screenshot. i don't see any missing SDP's, please correct me if i am wrong

1.
Early Offer Invite

Between Helios IP and CUCM

04608917.001 |16:23:27.808 |AppInfo |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 984 from 10.1.4.93:[5060]:
[938068,NET]
INVITE sip:3513@10.1.3.5 SIP/2.0
Via: SIP/2.0/UDP 10.1.4.93:5060;rport;branch=z9hG4bK15784
From: "Front Door" <sip:2042@10.1.3.5>;tag=28231
To: <sip:3513@10.1.3.5>
Call-ID: 744
CSeq: 20 INVITE
Contact: <sip:2042@10.1.4.93:5060>
Content-Type: application/sdp
Allow: REGISTER, INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, NOTIFY, PRACK
Max-Forwards: 70
User-Agent: 2N Helios IP Vario 2.6.0.13.7
Supported: 100rel
Content-Length: 540
v=0
o=- 1218278268 1162695338 IN IP4 10.1.4.93
s=HIP 2.6.0.13.7
t=0 0
m=audio 5000 RTP/AVP 0 8 101
c=IN IP4 10.1.4.93
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
m=video 5002 RTP/AVP 123 124 98 34
c=IN IP4 10.1.4.93
a=sendonly
a=rtpmap:123 H264/90000
a=fmtp:123 profile-level-id=42801E; packetization-mode=1
a=rtpmap:124 H264/90000
a=fmtp:124 profile-level-id=42801E; packetization-mode=0
a=rtpmap:98 H263-1998/90000
a=fmtp:98 QCIF=1; CIF=1
a=rtpmap:34 H263/90000
a=fmtp:34 QCIF=1; CIF=1

Source Filename: SDL001_100_000731.txt

--------------------------
2. Delay Offer 200ok

DX650 to cucm

04609131.002 |16:23:30.080 |AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 10.1.4.49 on port 41226 index 536 with 2522 bytes:
[938085,NET]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.1.3.5:5060;branch=z9hG4bK56122278d148
From: <sip:2042@10.1.3.5>;tag=302167~23001403-1e76-4ea5-8dd4-52d6f82b946c-27747696
To: <sip:3513@10.1.3.5>;tag=5cfc665d4a0d088022cc6b0e-33f1d21d
Call-ID: aa0caf00-4b6197ff-298c-503010a@10.1.3.5
Date: Wed, 14 Jan 2015 16:23:29 GMT
CSeq: 101 INVITE
Server: Cisco-CP-DX650/10.1.2
Contact: <sip:0bed8813-62a5-6dcf-6e3d-90cc088a245d@10.1.4.49:41226;transport=tcp>;video
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "Navjot Mary" <sip:3513@10.1.3.5>;party=called;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1
Allow-Events: kpml,dialog
Recv-Info: conference
Recv-Info: x-cisco-conference
Content-Length: 1451
Content-Type: application/sdp
Content-Disposition: session;handling=optional
v=0
o=Cisco-SIPUA 1129 0 IN IP4 10.1.4.49
s=SIP Call
t=0 0
m=audio 18126 RTP/AVP 0 8 18 102 116 101
c=IN IP4 10.1.4.49
a=trafficclass:conversational.audio.avconf.aq:admitted
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:102 L16/16000
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 27814 RTP/AVP 100 112 126 97
c=IN IP4 10.1.4.49
b=TIAS:4000000
a=trafficclass:conversational.video.avconf.aq:admitted
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=640028;packetization-mode=1;level-asymmetry-allowed=1;max-fps=6000;max-rcmd-nalu-size=256000
a=imageattr:* recv [x=1024,y=600,q=0.60] [x=1280,y=720,q=0.50]
a=rtpmap:112 H264/90000
a=fmtp:112 profile-level-id=4D0028;packetization-mode=1;level-asymmetry-allowed=1;max-fps=6000;max-rcmd-nalu-size=256000
a=imageattr:* recv [x=1024,y=600,q=0.60] [x=1280,y=720,q=0.50]
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=428028;packetization-mode=1;level-asymmetry-allowed=1;max-fps=6000;max-rcmd-nalu-size=256000
a=imageattr:* recv [x=1024,y=600,q=0.60] [x=1280,y=720,q=0.50]
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=428028;packetization-mode=0;level-asymmetry-allowed=1;max-fps=6000;max-rcmd-nalu-size=256000
a=imageattr:* recv [x=1024,y=600,q=0.60] [x=1280,y=720,q=0.50]
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=sendrecv

Source Filename: SDL001_100_000731.txt

-------------------------------------------

3. ACK w/SKP(101ACK)

CUCM to DX650

04609274.001 |16:23:30.093 |AppInfo |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP message to 10.1.4.49 on port 41226 index 536
[938089,NET]
ACK sip:0bed8813-62a5-6dcf-6e3d-90cc088a245d@10.1.4.49:41226;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.1.3.5:5060;branch=z9hG4bK56157cba769f
From: <sip:2042@10.1.3.5>;tag=302167~23001403-1e76-4ea5-8dd4-52d6f82b946c-27747696
To: <sip:3513@10.1.3.5>;tag=5cfc665d4a0d088022cc6b0e-33f1d21d
Date: Wed, 14 Jan 2015 16:23:27 GMT
Call-ID: aa0caf00-4b6197ff-298c-503010a@10.1.3.5
User-Agent: Cisco-CUCM10.5
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 482
v=0
o=CiscoSystemsCCM-SIP 302167 1 IN IP4 10.1.3.5
s=SIP Call
c=IN IP4 10.1.4.93
b=TIAS:768000
b=AS:768
t=0 0
m=audio 5000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=trafficclass:conversational.audio.avconf.aq:admitted
m=video 5002 RTP/AVP 123
b=TIAS:704000
a=rtpmap:123 H264/90000
a=fmtp:123 profile-level-id=42801E;packetization-mode=1
a=content:main
a=sendonly
a=trafficclass:conversational.video.avconf.aq:admitted

Source Filename: SDL001_100_000731.txt

----------------------
4. 200OK SDP to helieos ip

reply from CUCM to Helios IP initial Invite

04609291.001 |16:23:30.094 |AppInfo |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.1.4.93:[5060]:
[938090,NET]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.4.93:5060;rport;branch=z9hG4bK15784
From: "Front Door" <sip:2042@10.1.3.5>;tag=28231
To: <sip:3513@10.1.3.5>;tag=302166~23001403-1e76-4ea5-8dd4-52d6f82b946c-27747695
Date: Wed, 14 Jan 2015 16:23:27 GMT
Call-ID: 744
CSeq: 20 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Supported: replaces
Server: Cisco-CUCM10.5
Send-Info: conference, x-cisco-conference
Remote-Party-ID: "Navjot Mary" <sip:3513@10.1.3.5>;party=called;screen=yes;privacy=off
Contact: <sip:3513@10.1.3.5:5060>;video
Content-Type: application/sdp
Content-Length: 437
v=0
o=CiscoSystemsCCM-SIP 302166 1 IN IP4 10.1.3.5
s=SIP Call
c=IN IP4 10.1.4.49
b=TIAS:768000
b=AS:768
t=0 0
m=audio 18126 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 27814 RTP/AVP 126
b=TIAS:704000
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=428028;packetization-mode=1;max-rcmd-nalu-size=256000;level-asymmetry-allowed=1;max-fps=6000
a=content:main
a=recvonly

Source Filename: SDL001_100_000731.txt
----------------------------

Ayodeji Okanlawon · ‎01-14-2015

Barry,

I looked in detail at your logs and what I see is much more than how you have described this. Here is a more detailed sip ladder for this call flow. I have attached a clearer sip ladder diagram

Here is what this interprets as

+++1. 2N Helios IP sends an INVITE CUCM for DX650++++

INVITE sip:3513@10.1.3.5 SIP/2.0
Via: SIP/2.0/UDP 10.1.4.93:5060;rport;branch=z9hG4bK15784
From: "Front Door" <sip:2042@10.1.3.5>;tag=28231
--

User-Agent: 2N Helios IP Vario 2.6.0.13.7

+++2. CUCM sends the INVITE to DX650+++

INVITE sip:0bed8813-62a5-6dcf-6e3d-90cc088a245d@10.1.4.49:41226;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.1.3.5:5060;branch=z9hG4bK56122278d148
From: <sip:2042@10.1.3.5>;tag=302167~23001403
-
User-Agent: Cisco-CUCM10.5

+++At the same time CUCM sends the same INVITE to a CSF device on 10.0.0.74 (looks like this is a shared line with this device)+++

INVITE sip:0bed8813-62a5-6dcf-6e3d-90cc088a245d@10.0.0.74:63931;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.1.3.5:5060;branch=z9hG4bK561357876724
From: <sip:2042@10.1.3.5>;tag=302168~23001403-1e76-4ea5-8dd4-52d6f82b946c-27747696
---
User-Agent: Cisco-CUCM10.5

3++++ Next the CSF device transfers the call back to CUCM using a REFER+++

REFER sip:10.1.3.5 SIP/2.0
Via: SIP/2.0/TCP 10.0.0.74:63931;branch=z9hG4bK00000f5f
From: "Navjot Mary" <sip:3513@10.0.0.74>;tag=a0481c95c0c8011b00004aab-000079c2
To: <sip:10.1.3.5>
Call-ID: a0481c95-c0c8003e-00005423-00006685@10.0.0.74
Date: Wed, 14 Jan 2015 16:23:47 GMT
CSeq: 1001 REFER
User-Agent: Cisco-CSF
Accept: application/x-cisco-remotecc-response+xml
Expires: 3600
Max-Forwards: 70
Contact: <sip:0bed8813-62a5-6dcf-6e3d-90cc088a245d@10.0.0.74:63931;transport=tcp>
Require: norefersub
Referred-By: "Navjot Mary" <sip:3513@10.0.0.74>
Refer-To: cid:000069e6@10.0.0.74

And all sorts of things happened from there...

Here are the questions and suggestions

1. What is the CSF device on 10.0.0.74? Is this Jabber?

2. Is this a shared line between the jabber client and the Dx650

3. What seem to be happening is that the call is been extended to the Jabber device rather than terminating on the DX650.

Can you delete the extension number from the jabber client (for test purposes) and test again...

Please rate all useful posts

barry florence · ‎01-15-2015

Hi Ayodeji,

Thanks for the reply and detailed explanation. The extension is associated with a 8841 profile, dx650 phone and the csf windows jabber.

1. 10.0.0.74 is the jabber device

2. 3513 is associated with all the above 3 devices

3. when we answer in jabber, the call is working.

I have collected new logs with and without the jabber device, the logs for without the jabber device was at the time 9:07 .

Thanks

Ayodeji Okanlawon · ‎01-15-2015

Hi Barry,

I have looked at the logs at 9.07 and it looks okay. So what is the issue when the call is sent to the DX650? What happens? No video? No Audio? How should the helios system work?

Please rate all useful posts

barry florence · ‎01-16-2015

Ayodeji,

It is the same original issue even when we remove the jabber device, when someone pushes the button at the door entry system(10.1.4.93), it rings the dx650(10.1.4.49) and when someone answers, it gives a busy tone both at the dx650 and door entry( as in the traces3 logs 9:07). It works (both audio and video) for 8945 phone and windows jabber phones. The working scenario has to be as follows, when someone presses the button at door system, it rings the dx650 phone, when someone answer at the phone, user (dx650 user at 1st floor) will be able to see the video of the outside user, should be able to talk each other and the receptionist user dials a code to open the door.

Thanks

barry florence · ‎01-16-2015

Hi Ayodeji,

I just tried few things(like enable and disable mtp on the device, reset the device), it seems to work now partially, i mean when someone pushes the button at the door entry system(10.1.4.93), it rings the dx650(10.1.4.49) and we can answer it, they can talk each other however no video on dx650. I have attached the new traces again. Video calling is enabled on the phone and video calls are working with other phone.

(2N Helios IP ) door system(2042)-> cucm->DX650(3517)

Thanks

Ayodeji Okanlawon · ‎01-16-2015

The reason video is not working is because you have enabled MTP. The CUCM MTP doesn't seem to be able to support video hence the SDP sent to the DX650

This is the 200 ok sent to the helios, with video disabled. (please remove mtp, test again and send me the logs)

SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.1.4.49:46335;branch=z9hG4bK4c1606f6
From: <sip:3517@10.1.3.5>;tag=5cfc665d4a0d040129648ecc-7c9d4d27
To: "Door Entry" <sip:2042@10.1.3.5>;tag=377404~23001403-1e76-4ea5-8dd4-52d6f82b946c-27751563
Date: Fri, 16 Jan 2015 12:18:39 GMT
Call-ID: c9c2e500-4b91019b-3d52-503010a@10.1.3.5
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Supported: replaces
Server: Cisco-CUCM10.5
Call-Info: <urn:x-cisco-remotecc:callinfo>; security= NotAuthenticated; orientation= from; gci= 1-4559; isVoip; call-instance= 1
Remote-Party-ID: "Door Entry" <sip:2042@10.1.3.5>;party=called;screen=yes;privacy=off
Contact: <sip:2042@10.1.3.5:5060;transport=tcp>
Content-Type: application/sdp
Content-Length: 389
v=0
o=CiscoSystemsCCM-SIP 377404 2 IN IP4 10.1.3.5
s=SIP Call
c=IN IP4 10.1.3.5
b=TIAS:64000
b=AS:64
t=0 0
m=audio 27318 RTP/AVP 0 101
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 0 RTP/AVP 31 34 96 97
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
a=rtpmap:96 H263-1998/90000
a=rtpmap:97 H264/90000
a=content:main
a=inactive

Source Filename: sdl001_100_000863.txt

Please rate all useful posts

barry florence · ‎01-16-2015

Hi Ayodeji

Mtp was unchecked previously at the device level(dx650), I don't why it invoked the mtp. As cucm mtp was at the mrgl in device level in previous trace, This time i have created a new mrg and mrgl without the cucm mtp and applied the mrgl at the device pool and device level, tested the call again, this time it is back to the original issue (when someone pushes the button at the door entry system(10.1.4.93), it rings the dx650(10.1.4.49) and when someone answers, it gives a busy tone both at the dx650 and door entry, (no audio or video). I have attached the traces as requested.

Thanks

Ayodeji Okanlawon · ‎01-16-2015

This is really strange. I have gone over the logs again and everything looks okay. Its surprising that You don't have audio or video. You should atleast have audio. Please enable MTP so that you can atleast use the system even if its only audio that you get. I will continue to investigate this.

Please rate all useful posts