CUCM 9.0 on VM - SIP Contact Header issues

[mgorgeski]

Good evening guys,

My new forum place, my first questions here.

I come from a more traditional PBX world for the past several years administering Siemens HiPath4000 PBX (softswitch since latest version).

Cisco UCM is quite a new concept for me, VoIP from the ground up. It doesn't always makes enough sense but must admit it is a good concept.

Brief overview of the LAB architecture:

Linux Host ---> VMWare Workstation ---> ESXi ---> CUCM 9.0.1.10000-37

Bridged networking.

Call processing service on.

Linux Host IP:     10.10.80.103

ESXi IP:             10.10.80.104

CUCM IP:           10.10.80.105

On the Linux Host I have installed Ekiga SIP softclient.

CUCM has SIP Security Profile configured with Digest Authentication. Profile successfully applied to Ekiga SIP softclient.

Ekiga SIP softclient is configured with the physical nic MAC address.

NOTE: I have used different SIP softclients - same results.

Trace attached.

When I try to register Ekiga in CUCM registers successfully.

However, CUCM populates incorrect IP for Ekiga.

The IP is 192.168.236.1. This is VIRTUAL IP from vmnet1 virtual adapter on the Linux host. This virtual adapter also has its own different MAC address.

I have cleared CUCM's arp cache with utils network arp delete IP with no avail.

I have learnt how to trace the call. From the trace file I obtained, in the SIP registration can be found:

REGISTER sip:10.10.80.105 SIP/2.0

CSeq: 305 REGISTER

Via: SIP/2.0/UDP 10.10.80.103:5060;branch=z9hG4bKba9c9413-4a04-e311-83c5-84a6c8d35b03;rport

User-Agent: Ekiga/3.2.6

Authorization: Digest username="Ekiga", realm="ccmsipline", nonce="kYzZzVpXYNSC/zFrnGqrgkG/vamfLpc/", uri="sip:10.10.80.105", algorithm=MD5, response="36d51a9b63b97140dae1a45f0b9e957b"

From: <sip:1002@10.10.80.105>;tag=7aae6ff6-4104-e311-83c5-84a6c8d35b03

Call-ID: ecaa6ff6-4104-e311-83c5-84a6c8d35b03@LabMachine

To: <sip:1002@10.10.80.105>

Contact: <sip:1002@10.10.80.103>;q=1, <sip:1002@192.168.236.1>;q=0.667, <sip:1002@172.16.80.1>;q=0.334

Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING

Expires: 120

Content-Length: 0

Max-Forwards: 70

Apparently the Ekiga SIP client advertise THREE Contact addresses, out of which the Second (192.168.236.1) and Third(172.16.80.1) are Virtual IP address.

CUCM decides to register Ekiga on the second virtual IP (192.168.236.1) instead of the first physical IP address (10.10.80.103).

Any idea what can I do to force CUCM to prioritize registration on the first - physical IP address ?

Cheers

Mariano

[mgorgeski]

UPDATE:

Below I provide the SIP error message that probably is signaled from CUCM  due to the Registration Failure:

00038799.001 |00:00:41.060 |AppInfo  |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.80.103:[5060]:

[3218,NET] SIP/2.0 500 Internal Server Error

Via: SIP/2.0/UDP 10.10.80.103:5060;branch=z9hG4bKe4698b69-5b04-e311-8495-84a6c8d35b03;rport

From: ;tag=be538b69-5b04-e311-8495-84a6c8d35b03

To: ;tag=427366675

Date: Thu, 15 Aug 2013 21:00:41 GMT

Call-ID: 2c368b69-5b04-e311-8495-84a6c8d35b03@LabMachine CSeq: 7

PUBLISH

Warning: 399 CUCM "Unable to find a device handler for the request received on port 5060 from 10.10.80.103"

Content-Length: 0

Message was edited by: Mariano Gorgeski

[Ayodeji Okanlawon]

Mariano,

Have you checked the cucm group assigned to the device pool on your sip phone...Is this server 10.10.80.105 in that group? The error message

Warning: 399 CUCM "Unable to find a device handler for the request received on port 5060 from 10.10.80.103

usually means that the server has received a request from a device on a cucm group which it is not a part of

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[mgorgeski]

@aokanlawon

To the Device Pool assigned to the SIP softclient in question, indeed there is a CUCM Group containing the Server node 10.10.80.103 in it.

There are 3 individual handshakes processed based on the intial SIP REGISTER.

1. For the true Physical IP

2. For the erroneus Virtual IP

3. For the another erroneus Virtual IP

For the first Pusical IP fails with:

.SIP/2.0 500 Internal Server Error

Via: SIP/2.0/UDP 10.10.80.103:5060;branch=z9hG4bKe4698b69-5b04-e311-8495-84a6c8d35b03;rport

From: <1002>;tag=be538b69-5b04-e311-8495-84a6c8d35b03

To: <1002>;tag=427366675

Date: Thu, 15 Aug 2013 21:00:41 GMT

Call-ID: 2c368b69-5b04-e311-8495-84a6c8d35b03@LabMachine

CSeq: 7 PUBLISH

Warning: 399 CUCM "Unable to find a device handler for the request received on port 5060 from 10.10.80.103"

Content-Length: 0

For the first erroneus Virtual IP does:

SIP/2.0 401 Unauthorized

Via: SIP/2.0/UDP 192.168.236.1:5060;branch=z9hG4bKc69b8b69-5b04-e311-8495-84a6c8d35b03;rport

From: <1002>;tag=ba938b69-5b04-e311-8495-84a6c8d35b03

To: <1002>;tag=1283248697

Date: Thu, 15 Aug 2013 21:00:41 GMT

Call-ID: 2c368b69-5b04-e311-8495-84a6c8d35b03@LabMachine

CSeq: 8 PUBLISH

WWW-Authenticate: Digest realm="ccmsipline", nonce="oQk+vBO6nSypQqjSqtsrvBh1ycSOPK2b", algorithm=MD5

Content-Length: 0

For the second erroneus Virtual IP fails with the same reason as for the first:

SIP/2.0 500 Internal Server Error

Via: SIP/2.0/UDP 172.16.80.1:5060;branch=z9hG4bKa2b58b69-5b04-e311-8495-84a6c8d35b03;rport

From: <1002>;tag=82ad8b69-5b04-e311-8495-84a6c8d35b03

To: <1002>;tag=563452351

Date: Thu, 15 Aug 2013 21:00:41 GMT

Call-ID: 2c368b69-5b04-e311-8495-84a6c8d35b03@LabMachine

CSeq: 9 PUBLISH

Warning: 399 CUCM "Unable to find a device handler for the request received on port 5060 from 172.16.80.1"

Content-Length: 0

BUT(!) It keeps exchanging NOTIFY with the "Unauthorized" Virtual IP.

[3227,NET]

NOTIFY sip:1002@192.168.236.1 SIP/2.0

Via: SIP/2.0/UDP 10.10.80.105:5060;branch=z9hG4bK192b9986b7

From: <1002>;tag=321194372

To: <1002>

Call-ID: bc865180-20d14178-c-69500a0a@10.10.80.105

CSeq: 101 NOTIFY

Max-Forwards: 70

Date: Thu, 15 Aug 2013 21:00:40 GMT

User-Agent: Cisco-CUCM9.0

Event: message-summary

Subscription-State: active

Contact: <1002>

Content-Type: application/simple-message-summary

Content-Length: 22

I can bet H323 would never ever do this.

And it finaly registers that one. From where the hack is coming this strange behaviour with the CUCM?

Trace attached.