I recently upgraded my Asterisk installation from 1.6.2 to the recently released 1.8.0. Although I've learned to shy away from unnecessary Asterisk upgrades (IMHO, when dealing with Asterisk, it's best to abide by a strict "if it ain't broke, don't fix it" policy) I decided that the fact that 1.8 is going to be a Long Term Support release made it worth the risk. Although the scope of building, installing, or upgrading Asterisk is outside of the scope of this article (WAY outside), I was pleasantly surprised to find that the upgrade was relatively painless. In fact, without making any changes to my particular configuration (save for installing a version of the G.729 codec which was compatible with the new distribution) everything worked right off of the bat.

Upon checking out the console however, I noticed an odd error that I hadn't seen under the previous distribution. Although calls still seemed to complete correctly, I noticed the following:

WARNING[17468]: chan_sip.c:12888 __set_address_from_contact: Invalid contact uri spqalyv7.8134:00tasotupCsoC76G80 (missing sip: or sips: ), attempting to use anywayERROR[17468]: netsock2.c:245 ast_sockaddr_resolve: getaddrinfo("spqalyv7.8134", "00tasotupCsoC76G80", ...): Servname not supported for ai_socktypeWARNING[17468]: chan_sip.c:12899 __set_address_from_contact: Invalid host name in Contact: (can't resolve in DNS) : 'spqalyv7.8134:00tasotupCsoC76G80'
After some searching, I determined that the garbled entries I was seeing in the console were related to the "fullcontact" column in my SIP MySQL Realtime table. In previous versions of Asterisk, this column held a sort of URL which was generated when a peer or client registers with Asterisk. Under Asterisk 1.8, that information is corrupted for some reason. After a bit of trying to sort out why the corruption was happening, I decided to simply delete the "fullcontact" column and see what if anything would happen (as a side note, my recollection is that the realtime driver creates columns as needed, so I figured that at worst the deleted column would be automagically recreated).

Strangely enough, deleting the "fullcontact" column fixed the problem. Keep in mind that I don't fully understand why this database column (apparently) isn't needed any more so take this entry with a grain of salt. However, if you're seeing these entries in your Asterisk console, perhaps this will give you a point in the right direction.