We are using DNS SRV records with the CUCM/CUPS integration and we are using the SIP Publish method for exchanging presence information between the CUCM and CUPS. I haven't been on site in months and as far as I know everything is functioning, though I have an admin who is asking me why the CUPS Troubleshooter is showing the following warnings and errors:
2. Warning: Possible missing SIP trunk on Cisco Unified Communications Manager. Each Cisco Unified Presence server should have a corresponding SIP trunk configured (unless DNS SRV is enabled). Possible missing entries include: xxx
3. The port for the SIP Publish Trunk on Cisco Unified Communications Manager does not match any configured ports for the Cisco SIP Proxy Listeners on the Cisco Unified Presence server
It has been a while but I believe that these are erroneous messages. Message #2 is definitely erroneous and it says that if you are using DNS SRV, then no worries. I also believe that I always had Message #1 and things validated/functioned as expected. But I figured it would be worth checking with others to see. I did check to make sure that the SRV record resolves to valid and reachable hosts.
For message #3, I also think this is bogus. When I configure the SIP trunk in CUCM and enable SRV (record that points to the CUPS cluster), the port number automatically changes from 5060 to 0. I think that this is what message #3 is complaining about. Again, I believe this all works but I am double checking to see if the above messages are expected when using SRV records between a CUCM and CUPS cluster.
I seem to have misplaced Michael's book so I thought this would be the next best thing ;-)
No, I have not. I tried to check the defect to see the specifics and determine if all three of my warnings/errors are addressed in the defect. However, this defect isn't publicly viewable. Do you know if all three of my warnings/errors are "expected" (i.e. part of this defect)?
I am confused and interested more in your configuration of DNS SRV. I am not a DNS person.
I have two DNS SRV records created, one for CUCM and one for CUPS. I am most concerned with the one you configure on the CUCM SIP Trunk. My DNS SRV record is configured as so:
Host that handles this service: pres01.domain.com
Host that handles this service: pres02.domain.com
Now, putting _sippres._tcp.domain.com on my SIP Trunk in CUCM isn't allowing a SIP connection to form and I don't receive presence status. CUCM can't resolve the DNS SRV either. I've read that you do not need to put the "_sippres._tcp." portion, but that just leaves my domain name "domain.com".
I see in other examples, including yours that you added a hotsname after the "_tcp" so it appeared as "_sip._tcp..domain.com". I don't see where you add that hostname in the DNS SRV record. Am I missing something?
The only other option that I can think of is create a new A record that points to both of my CUPS servers such as "pres.domain.com". Then remove my DNS SRV records and create one just like:
Service: _sippres or _sip
Host that handles this service: pres.domain.com
Then in CUCM, don't add the "_sippres._tcp.pres.domain.com", but just put the "pres.domain.com" and check the "Destination is an SRV" checkbox. Is this the correct way of doing it? It seems like it would juts be acting more as an A record than a DNS SRV at this point.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...