Recently upgraded our VCS Starter Pack to 7.03. No issues with the upgrade but once complete Jabber / Movi clients can no longer register. Endpoints such as the EX90's have no trouble. I have not been able to find a root cause.
Has anyone seen this after an upgrade?
check your registration policy settings. This could be changed due to the upgrade and not allow the provisioning request to succeed
is the SUBSCRIBE from Movi responded to with a 200 OK message? If yes, does the provisioning service proceed and send a NOTIFY message to the Movi client?
yes i see the 200 ok
||SIP/2.0 200 OK|
Via: SIP/2.0/TLS 220.127.116.11:1151;branch=z9hG4bKfc0fbad270b0cd5e2f33b23c1805ae1d.1;received=18.104.22.168;rport=1151;ingress-zone=DefaultZone
and the Notify:
Addtionally i dont see anything abnormal with the communication from the client side.
can you verify that the NOTIFY gets delivered to the Movi client?
Also, inside that NOTIFY message, you will see a section tagged with '
You need to verify that the Movi client is able to resolve this address in DNS, preferably with the help of Wireshark which will show you the DNS lookup and any replies which come back.
You will need to take a diagnostics log with the Network log level set to 'DEBUG' in order to see the actual payload contents of the NOTIFY.
Yes you can see in the logs the vcs (video.amc.edu) assigned through the provisioning process.
Local host can resolve the address
The client successfully gets the provisioning info and attempts to register to video.amc.edu. Thats where the trail stops.. Is there a way to debug the registration events?
This is the contents of the notify message i meant to cinclude in the previous post.
Enable network log level to Debug. Stop logging once you have tried to log in. Then download the log and open it in the SMART tool developed by Cesar Fiestas and see if you can see anything odd. There is a link to the SMART tool here:
Hope this helps.
if you look at the NOTIFY, you will see that both the Sign on URI, Presence URI and Phonebook URI are all missing the domain portion of the URI (unless you manually removed those parts for privacy) and if that is the case then that would most likely be the cause of the registration failure, as the syntax would be incorrect.
Can you confirm that you did not remove the domain portion yourself, and that what you posted is the actual NOTIFY?
|Feb 8 08:53:20 video tvcs: UTCTime="2012-02-08 13:53:20||391" Module="network.sip" Level="INFO": Dst-ip="22.214.171.124" Dst-port="1151" Detail="Sending Request Method=NOTIFY||Request-URI=sip:email@example.com:1151;transport=tls||Call-IDfirstname.lastname@example.org"|
|Feb 8 08:53:20 video tvcs: Event="Request Sent" Service="SIP" Src-ip="126.96.36.199" Src-port="5061" Dst-ip="188.8.131.52" Dst-port="1151" Protocol="TLS" Method="NOTIFY" To="sip:email@example.com:1151;transport\=tls" Level="3" UTCTime="2012-02-08 13:53:20||391"|
could you describe exactly which values you have configured the Movi client with (username, internal/external server and SIP domain) as well as provide screenshots of the 'Edit user account' and the devices/location page for the 'testmovi' user?
Also, does amc.edu exist as a SIP domain on this Starter Pack VCS?
I've done a quick test on a Starter Pack in my lab, and I think I have found what your problem is.
Does the "FindMe ID (dialable address)" of this user happen to be simply 'testmovi' without any domain?
If so, then this is your issue. The FindMe ID should normally be an URI-type address, in your case most likely 'firstname.lastname@example.org', and in my lab I can reproduce the NOTIFY seen in your environment if the FindMe ID is set to 'testmovi' rather than 'email@example.com'.
What are the settings in TMS?
I did a quick check and our domain is included in the provisioning response:
yeah, saw that after klicking on post. I was a little to fast on the send button ;-)
But the TMS Agent on the Starterpack VCSX should send the same provisioning request, right?
Settings of course are minimal on the client. No changes to the domain or addressing
As you can see the EX90 registers and can make and take calls without any issue.
as per my earlier post today, please change the FindMe ID from 'testmovi' to 'firstname.lastname@example.org' and your problem should go away.
I assume that the EX90 either has a proper URI-based FindMe ID and/or that this device is not using provisioning but is rather manually configured with H323 and SIP settings, and that this is why the EX90 is not showing similar symptoms.
THATS IT! This is definately a change from the previous version. None of our existing accounts are defined this way. It never would have occurred to me to try this. I am sorry that I overlooked the first time you suggested this change.
Thanks so much for your help!
I'm glad to hear it's working now.
As a side note, I would always recommend using a publicly routable URI for FindMe ID if you are planning to make calls to external parties. If your FindMe ID is simply 'testmovi' and you place an external call, and if Caller ID is set to FindMe ID on the VCS, the caller will be presented as 'testmovi' which will normally not allow the callee to call back at a later time (Or call back a missed call) since 'testmovi' is not a publicly routable number/alias, while 'email@example.com' is.