I have recently installed Cisco Jabber Video 4.4 (beta) on my home PC (windows XP and windows 7) I am unable to connect to Cisco Movi uses ( Movi 4.3) via my company Express server, any ideas re what I can do to overcome this issue would be much appreciated.
First thing I would look at is the VCS-E logs to see if you're actually hitting it at all, and if you are, what happens to the call from then onwards. (The error message you get when attempting to connect could give you a clue as well.)
Is it only JabberVideo (aka Movi) users you cannot connect to? Can you connect to other SIP devices, i.e. end-points behind the VCS-E at all?
If these do not connect, will they connect if using Alias@VCS-E_IP_address instead of Alias@domain?
If yes, then there is a DNS issue, most possibly lack of SRV records, if no, then there is countless possibilities involving VCS-E configuration incl. zone authentication setting etc etc etc.
I'll try it here when back at work Monday morning just to make sure it works as we're using 4.3 at work as well, and I know this works fine whether I'm external or internal - so I'll be surprised if this "free" version behaves any differently.
Can you, in fact connect to any other sites, i.e. firstname.lastname@example.org ? (This is a C20 which will loop your video back to you and it works fine for me).
Thanks Jens, our network admin team have looked at the VCS-E logs and have not been able to find a trace of the incominng call.In answer to your question, I will attempt to test the calls to end points as you have described, previous attempts direct to the device to the alias have failed. The call to the loopback alias worked so it definitely looks like our network envoirenmnet is the cause of the issue, I'm not sure if it helps, but I can successfully call from JabberVideo ( AKA Movi) via the VCS-E to any Jabber 4.4 user. If you are able to share any information regarding possible configuration issues in the VCS-E that would be appreciated.
The fact that no trace is found of your incoming call points very much towards a DNS issue.
You can confirm this by attempting to connect from an external endpoint using SIP and replacing the domain with the IP address of the VCS-E; alias@VCS-E_IP_address.
If that doesn't work, then you might have a combination of issues, but first check to see if the appropriate SIP SRV records are in place, should really have three; udp, tcp and tls.
I am assuming your VCS-E either sits in the public - or if in DMZ, the appropriate inbound ports are open.
See https://supportforums.cisco.com/docs/DOC-23227 for port info.
The plot thickens;
I've just discovered, through further testing, that this "free version" will not play nice with the "not free version", at least not in my case - the calls will connect, but getting no video and only occasional one-way audio.
Connecting "not free" to/from "not free" works fine though.
Did some investigating on our network too, made test call as you suggested to Alias@VCS-E_IP_addressand call was detected by express gateway logs but was unsuccessful, we checked further and found that SIP SRV tls has been disabled by our server team to support a trial of Microsoft Lync, is the tls service critical to the success of the Jabber call and do we need to disrupt the trial of Lync to test further?
I wanted to jump in to let you know that I had a call today from my enterprise client jabber4.3 to a free Jabber4.4 and had no issues. Video was great. We were connected at 768Kbps for about 30 minutes. My SIP TLS setting is on in the Expressway.
That's good news for you - but more frustrating news for me
Heh - just heard that Cisco is aware of the "media issue" and that they are working on a fix.
You can see the weird problems I'm having in the other thread.
Alias@VCS-E_IP_address should work regardless of SRV records being in place or not as you're bypassing DNS, however, it has to be a specific SIP address, otherwise it won't work.
I.e. for our office system we use an E.164 Alias for H323 calls and a SIP URI for, well, SIP calls
You will need to have those SRV records in place though for alias@domain to work though, but I don't think I would disrupt the Lync trial for this.
I am running into some strange issues at the moment connecting 4.3 and 4.4 to each other;
take a look here: https://supportforums.cisco.com/thread/2137267?tstart=0
Edit: Just realised I've forgotten an important part of the puzzle...to get alias@IP_address to work you also need to implement a pre-search transform on the VCS-E which replaces IP_address with the domain of your choice;
Pattern type: Suffix
Pattern string: IP_address
Pattern behaviour: Replace
Pattern string: domain
..and the appropriate search rules...
Without any changes made to our corporate envoirenment I have now made some test calls from the 4.4 client on my home desktop to an MXP 1700 on our network and the call is intermittently successful, still no luck with calls from 4.4 to 4.3 though.Is there the slightest chance that given the 4.4. client has to register to the Cisco "cloud" that there are changes being made by Cisco in their "cloud" that are affecting results.
Yeah, well, it is a beta version, so Cisco would be making changes as different issues are discovered by different users.
What had me going was the fact I could not get 4.3 and 4.4 to play nice, but connecting the two together on our Codian MCU worked fine - and then finding out from other users that, no, 4.4 and 4.3 worked perfectly together.
Heh, I had one Cisco engineer telling me "no, it won't work" and another Cisco engineer telling me "yes, it works fine".
Turned out they were both correct, 4.4 and 4.3 works for at least some users, particulary if located in USA/Canada, whereas other users, myself included, have the "one way" media problem - which they are aware of.
At least now I know it's got nothing to do with what happens here at my end.
You might want to look at the logs of the unsuccessful calls though and see it you can see how far they get before they fail. Does the same thing happen with other sites, i.e. email@example.com, or is it only happening when connecting to a device on your network - will 4.3 consistently connect from your external site to the 1700?
If it does, then you might have to do a wireshark trace between your 4.4 and the 1700 to see what's going on.
I just tried a few calls now from home, with very mixed results, only one connected, but no media - however, I don't know if the very wet weather we're having here at the moment could be partly to blame as I'm on ADSL at home, which mean copper, potentially flooded pits etc. We've had over 300mm of rain during the last few days and forecast is for up to 400mm more during the next 24 - 48 hours.
Things are looking up; just had a call from "free" Jabber 4.4 on a Mac to my "enterprise" 4.3 on Win 7, worked great, even presentations both ways - so something has been changed very recently.
Shall be interesting to see if it works from my home this afternoon too, heh - if I still have internet connection that is, was a bit "interesting" weather here during the night.
Back to square one by the looks of things, tested a few minutes ago and;
a) 4.3 <--->4.4 no video either direction, audio only from 4.4 to 4.3 (both Mac and PC)
b) 4.4 <---> 150MXP/3000MXP works fine.
c) Deleting external server setting and domain and changing the internal server on 4.3 to
then logging in to my free Jabber account with this gives me one way media from "modified" 4.3 to "proper" 4.3,
which is a 50% improvement on point "a"
I think I'll just leave this alone for a while, my head is hurting and there's a big indentation in the brick wall...
I know that the 4.4 version of Jabber Video is not in general avaliable for enterprice customers yet, but have you tried to test 4.4 versus 4.4 ( registered with enterprice settings ) ? Between 4.3 to 4.4 it basically is a lot of testing with the jabber video back-end. We have seen your error report, and we have not been able to re-produce at all in our network ( Oslo, Norway ).
Could I also ask wheter you provision ICE on your enterprice VCS network for the 4.3 clients? That would be of interest.
Nope, haven't tried that as yet - I'll have to work this Sunday, so I'll try it then, and yes, I'm provisioning ICE for 4.3, I'll turn that off and see what happens.
Interesting thing is they play nice when bridging them on our Codian 4520.
This is interesting indeed. We have done some tests indicating that the combination with ICE, Cisco Jabber 4.3 and a certain amount of packetloss, we migth end up with "No media" scenarios.
So, I would hope that either running 4.4 all over ( ICE issues are fixed ) or by disabeling ICE on the VCS provisioning for 4.3 would help. The reason it works great with the MCU in the middle, or to most other endpoints, is that the MCU does not announce ICE capabillities, hence the ICE interop issues will not be provoked. Crossing my fingers for this to make your deployment more successfull.
Aha - that makes perfect sense.
Thanks for the heads up, it shall be interesting to see how it goes tomorrow morning.
And we have a winner!
Turning off ICE did the trick.
I've documented my tests below just in case someone else is having similar issues:
4.4 <-->4.4 both registered with Cisco, both located behind our FW: all OK.
4.4 <-->4.3 as above - all OK.
4.4 registered with Cisco <--> 4.3 registered locally: media received ok from 4.4 - no media received from 4.3
4.4 registered with Cisco <-->4.4 registered locally: initially no media at all, "one way media" from Cisco registered client after initiating presentation on this client.
4.4<-->4.4 both registered locally: all OK.
4.4 registered locally <--> 4.4 registered with Cisco: all OK
4.4 registered with Cisco <--> 4.3 registered locally: all OK
Also noticed 4.4 (after liberating it from Cisco servers) indicates max BW as 4Mbps whereas 4.3 only gave me 2.1
Odd Arild: Du trenger ikke krysse fingrene lengre - takker saa meget for info - skru av ICE hadde jeg nok aldri tenkt paa aa gjoere.
Great, though I would have expected the scenario with 4.4 on both ends, with ICE to work.
Any logs on this specific scenario would be great to have a look at.
Do you have any specific rules on the expreway VCS ? Some IP adress transforms, etc that could cause the ICE implmentation to get a bit confused ?
Also, what version are the VCS-E running ?
I re-tested this morning and looks like I got a couple of the previsous test results mixed up
4.4 registered with Cisco <--> 4.4 registered locally; ICE on = all ok
4.4 registered with Cisco <--> 4.3 registered locally;
ICE on = one way media from 4.4 after starting presentation,
ICE off = all ok.
Mind you, I haven't got a provisioning template for 4.4 so ICE says "version 4.3" - don't know if this impacts the 4.4 <--> 4.4 test.
We're on x7.1 by the way.
Thanks for the re-test, though the 4.4 version would probably not run with ICE towards the local VCS, since the setting was a 4.3 only provisioned setting. If you would like to isolate this test for 4.4 only, it should be easy to upload a 4.4 template to TMS by copying the 4.3 template, and edit the xml slightly.
The xml should be part of the official 4.3 distrubution zip. Rename the file to JabberVideoProvisioning4.4 and modify the first line of the xml ( replace 4.3 with 4.4) ( See under, and ups... there is still some pointer to Movi left )
This way you could enable ICE for the 4.4 clients only.
Again, just if you have time and would like to verify the 4.4 ICE implementation.
Uploaded 4.4 provisioning template and enable ICE v4.4:
No media either end initially - media received from Cisco registered 4.4 after initiating presentation on this - no media received from locally registered 4.4.
So, same result as 4.4 <--> 4.3 with ICE on.
The incoming call quality from 4.4/Cisco was noticeably much lower with ICE on.
I've attached tracelogs from the VCS-E for "ICE off" and one for "ICE on".
Apologies for not contributing over the last couple of weeks, I have been on holiday. I caught up with our Cisco account manager a few days ago to let him know that we continue to have issues with connecting calls from Jabber 4.4. to devices within our corporate envoiremnment using the domain addresses of the devices, also, that I have no issues when I replace the domain adress with the IP address of the VCE. My question was, is Cisco aware of any problem relating to their "cloud" DNS resolution that may be a factor in this issue? The answer from the account manager was, "yes, Cisco are aware of the issue, he admitted that Cisco seriously underestimated the interest in Jabber 4.4 and they had not provided sufficient back end infrastucture to support the trial, the errors that I am experiencing are re-produceable at other locations and that Cisco in due course will resolve the problem", he gave me no timeline for the fix. While I fully understand that we are taking part in a Beta tria, I must say I am disappointed with Cisco's performance and their ability or willingness to respond to issues identified in this discussion as well as the many others that are taking place with regard to Jabber.
Thanks Andy, that information is very much appreciated.
Hope you had a great holiday
I do hope Cisco get things locked down properly rather soonish so we won't run into more problems, as we're just about to roll out the free version to all of our undergraduate students - we're not a very big university, but we are still talking about around fifteen thousand potential users, and we need these to work well with around 3000 enterprise version users, being staff and postgrads. Shall be interesting to see how this evolves.
I've still to see any feedback from Cisco after uploading the VCS logs re our "ICE issue", so got no idea if this has been fixed. Guess I'll have to turn ICE back on again and see what happens...
Sorry for loosing the ball a bit on this one. However, I am still very interested in the 4.4 usecase wher ICE seams to fail.
Would it be possible to provide client loggs for a 4.4 <-> 4.4 ICE call, preferably from both clients.
Do you know how to collect logs from the client ?
On windows there is a Logs.ini file in this directory
Could you please make sure to add these lines, save and re-start the client.
When you now run the client, this will leave a sip.log file and a ice.log file. These would be of interest from both clients in the situations where media i failing.
NB! If you are using MAC, you can set the same logging by
defaults write com.cisco.JabberVideo LogLevels -dict-add SIP DEBUG ICE DEBUG HTTP DEBUG
defaults write com.Cisco.JabberVideo LogFiles -array-add HTTP ICE
Again, sorry for the radio silence. We have not been able to re-produce any of the 4.4 to 4.4 ICE issues you see.
No worries at all
It's Friday evening here now, so I'll get it done when back at work first thing Monday morning and l'll upload the logs here.
Tested again and same result when ICE enabled for 4.4.
Turning off ICE and all is well.
Attached logs from both enterprise and free versions, both 4.4
Laptop with free version was located behind our firewall, but connects fine to all external sites, and also to our internal sites where it enters our network through our VCS-E.
Tried testing from home first, but my ADSL connection was just to flaky this morning.
These logs were really pointing giving some great hints of what migth causing the issues.
First of all, I would be interested in understanding your internal VCS deployment. It is clear from the logs that there is some mangeling with the ICE candidates in your VCS deployment, and hence, ICE does not negotiate succesfull.
In fact, this is good, because the issue we see is a effect of the failure of a succesfull ICE negotiation.
I notice that we have not recieved the SIP log from the free client. I noticed also that in your logs.ini file, you have two declarations of the SIP debug flagg. It seems that the client reads the first, and ignores the second. Hence, no SIP logs
It would be interesting to have the SIP log from the external client as well.
So, thanks for the logs, we will start look into this error scenario ASAP.
But at the same time, ICE seams to fail with the current VCS set-up. Do you have clusters ? Forced interworking etc. etc...
I am not a super expert in does and donts on VCS set-up. Maybe this would be worth a request through the VCS support channels ?
Ok, don't know how I ended up with two SIP declarations, anyways, I'll give it another try when back at work tomorrow morning and upload the log files here.
Pretty simple set-up: two stand-alone VCS-C neigboured to each other, one VCS-E with two traversal zones, one for each VCS-C.
Only one VCS-C is used as SIP registrar for internal JabberVideo clients.
External users registers to VCS-E with authentication to AD done by VCS-C for both internal and external registrations.
Provisioning VCS-E as TURN Relay server, mind you, I'm currently missing TURN SRV record.
No forced interworking.