One way audio only on analog calls/faxes over SIP

[iflylow74]

Hi all,

I'm having some problems dialing from a third party SIP device. We have CUCM 10.5 on our campus. The device is a JK Audio AutoHybrid IP2 that has two extensions assigned to it. I had previously programmed one of these devices and it worked just fine. The department that uses the AutoHybrid had some issue (no idea what) and decided to do a factory rest on the device. They gave it to me to re-configure. Long story short, they ultimately send the device back to the manufacture and we now have a new one for me to configure.

The device has been configured and is registered and has a GUI where you dial numbers, answer etc. We have four digit dialing on campus but for some reason, dialing four digits fails every time. I ran a Wireshark capture and I'm getting the SIP Status 404 Not Found error.

The funny thing is, if I dial the number plus @ and the IP of one of our CM subscribers (1234@192.168.1.1), the call goes through just fine. Dialing off campus has the same issue.

[Chris Deren]

Can you assign a URI to the DN?

[iflylow74]

Hi Chris,

I'm fairly new to CUCM but I will give that a shot, thanks for the reply!

[iflylow74]

Just noticed the subject of my first post is wrong. Should just say can dial from third party SIP device :-)

[iflylow74]

Assigned the URI to the DN's (I believe correctly) with no luck. Strangely, for some reason only one of the lines on the device registers.

In CUCM, it shows partially registered. Everything seems to be setup the same on both lines and users.

[Todd Hebert]

If you are still following this thread, please respond.  I am having a very difficult time getting my device to register to CUCM.  Checking syslog it shows device type=336 trying to register, which is a 3rd Party Basic and I'm getting an error code 30, then immediately an error code 3.  I've tried rebuilding this device as advanced and basic several times with digest authentication enabled and disabled and tried several combinations of username with just the 4-digit DN vs user@domain and with and without domain name as well as in the Auth section of the device.  The Device Pool applied, CM group I'm using the 1st in the list.  I have several other vendors 3rd party SIP devices registered and working, just having trouble with this one.  Any clues would be helpful.  Thanks everyone.

[iflylow74]

One thing I have ran into with different SIP device vendors is trying to figure out their terminology. I had one 3rd party SIP device that I could not get to register no matter what I tried. One of the configuration settings was called "domain" so I put in our campus domain, nothing.

I finally tried using the CM IP address for the domain and it instantly worked! Very frustrating trying to decipher what each different vendor uses for terminology.

Not sure if this is helpful or not but wanted to put it out there as something to look at.

[Todd Hebert]

I appreciate the response.  In that particular field where it says domain, I've tried both my top-level domain in CUCM and just the IP address of the subscriber in my CM Group.  I spoke with JK Audio support and sat on the phone for over an hour, unfortunately they don't have a Cisco guide for configuring their device they can only assure me they have customers with this device connected to CUCM.

[iflylow74]

Funny you should mention JK Audio, one of the third party SIP devices I had trouble with is their AutHybrid IP2 device. Is that the device you are working with? 

[Todd Hebert]

That's the one.  I got it figured out.  Turns out I had a faulty network drop and was losing packets so it was timing out trying to register from the original location.  I got it working at my desk.  For domain setting on the device just put the IP address of the CUCM.  When you build it in CUCM, use 3rd Party Basic and assign a device security profile "Standard non-secure" no digest authentication, standard SIP profile worked for me and assign the digest user on the device, CSS, etc...  On the user account assign a digest password and give the account the ability to login like you do for users accessing the self-care portal.