cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
650
Views
0
Helpful
7
Replies

Strange CM-Group Behaviour

Peter Bishop
Level 1
Level 1

Unified Communications Manager 9.1.2

(1 Publisher - 7 Subscribers - 2 TFTP Servers)

 

We have recently added some SIP softphone clients in our UCM and during our testing we found that in certain cases if you called a SIP softphone from an IPT phone - (SCCP) and the SIP softphone then made an enquiry call to another IPT phone - (SCCP) and tried to transfer the call, the original calling party dropped out.

We could repeat this test from another IPT phone as the calling party and it would work.

We ran a matrix of tests - phone type; phone loads; etc. and found that the issue was related to the Device Pool the originating IPT phone was in.

So in further matrix testing, we found that if we changed the CM-Group in the device pool, we could get it to work every time.

So now looking at the Device Pool, we then determined, that with 2 of our 7 CM-Groups, the testing worked, with the other 5, the calling party was dropped.

So looking at the CM-Groups, we have a set up similar to this:- (We have 2 data centres 'A' & 'B')

 

CM-Group 1 - A-Sub01, A-Sub02, B-Sub01

CM-Group 2 - B-Sub01, C-Sub02, B-Sub01

CM-Group 3 - B-Sub02, B-Sub01, C-Sub02

and 4 others..............

 

So with CM-Groups 1 & 2 in the Device Pool, the calls worked, with all the others, the call dropped out.

The common factor in the successful calls is that both Data Centre Sub-01s are the subscribers that the phones are registered to.

In the failed call scenario, the phone is registered to the Sub 02 or Sub 03 subscribers.

 

I have been into Call Manager Serviceability and all Subscribers are running all Network Services.

 

The only difference in the Feature Services, is that the 'Sub-01' subscribers are also running 'Cisco WebDialler Web service.

 

I turned this feature on Subscribers -02 and changed the phone to have this as their '1st Choice Subscriber in the CM-Group, but it made no difference, as I didn't think it would.

 

Apart from that 1 service, I cannot see anything different between the 'Sub-01s' and the other Subscribers.

 

Has anyone got any other idea what might be causing this?

 

I've ruled out Media Resources / MTP etc., as I can definitely reproduce it just by changed Device Pool / CM-Groups.

 

Thanks,

Peter

 

**********************************************************************

Further update to this testing.

 

The SIP softphone clients are all Wave softphone clients and in the Wave programming, you can assign 4 'SIP' registrars which is configured to A-SUB01, A_SUB02, B-SUB01, B_SUB02. However, this doen't seem to affect anything.

If this configuration is changed to make A_SUB02, the priority registrar, and the Device Pool of the Calling IPT phone have a CM-GROUP where A_SUB02 is 1st choice Call Manager, the Call succeeds, so the issue is not related to difference in Subscribers.

 

However, the issue is related to the Subcriber the Wave server is configured to a registrar and the Subcriber the Calling IPT phone is registered with.

 

As a call could come from any IPT phone which could be registered with any 1 of 7 subcribers, this is still going to be an issue.

 

Does anyone understand the SIP registration from an External Server in 9.1.2 rather than SIP phone registrations? Is there any Exterprise Parameter that allows registration with multiple Subscribers?  I can't see one.

 

Thanks,

 

Peter

7 Replies 7

Brian Meade
Level 7
Level 7

Pull CallManager traces from all nodes for working/non-working scenario and I will take a look.

Hi Brian,

thanks for your offer of help. In the attached files there is the failed call – the details of which are shown below:-

Calling Party – (IPT SCCP Extension)                         808226                  10.221.115.98

Called Party – (Wave Softphone SIP Client)          51081                    161.2.123.189

Call succeeds OK up to this point.

The Wave Softphone SIP client – (51081) - then makes and enquiry call to:-

                                                                                                55152390             10.221.115.11                     (MAC – 3CCE7359D37A)

Call succeeds OK up to this point

The Wave Softphone SIP client – (51081) - then presses the ‘Transfer’ softkey and the call which was being held on 808266 drops out.

I can see the start of the call in the 1st file at 14:28:10.233 and it carries on into the 2nd file where it looks like there is a SIP ‘BYE’ signal sent, but I can’t see the reason code that might point to why it is being dropped.

As mentioned, if the Originating Party – (808226) – for example is registered to the same Subscriber as the Wave Softphone SIP client, then the call is transferred correctly.

I'll try and get traces for a good call, but the guys configuring the 'Wave' SIP softphones are not here at the moment.

Thanks,

Peter

We're going to need the traces from node 11 as well since that is where 808226 is registered and where the TransferManager process lives for this call.

 

The release request is coming in from node 11 as well:

46324487.000 |14:28:26.899 |SdlSig-I |CcRelReq                               |restart0                       |LineControl(10,100,167,73194)    |Cdcc(11,100,212,176113)          |10,100,238,1.310271^161.2.123.189^*      |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI=185106206 CI.branch=0  c.l=0 dtmCall=F dtmDisconn=F dtmMcNodeId=0 FDataType=0opId=0ssType=0 SsKey=0invokeId=0resultExp=Fbpda=FTransparentData=null CanSupportSIPTandN=false TransId=0 AllowBitMask=0x0 UserAgentOrServer= OrigDDName=locale: 1 Name:  UnicodeName:  pi: 0 mCallerId= mCallerName=

 

The issue is probably some sort of race condition though with the incoming BYE after the REFER is accepted being very quick and before the TransferManager process can complete the transfer.  We'll node the traces from the other node and possibly the working example traces in order to confirm.

Hi Brian,

I have remade test calls and put the final called party into the same CM-Group as the SIP softphone client, which I hope makes the tracing easier. I also had to use a different SIP softphone client, so here are the call details for the attached traces. I have added additional information, which I hope helps.

 

Call made at 15:00 on 19th May

Originating Party (SCCP 7911 phone)    Called Party (SIP Softphone) Final Transferred Party

808226                                                        51086                                        55152390

08173514671A                                          BADF00D2F00D                     3CCE7359D37A

10.221.115.98                                            161.2.123.189                          10.221.115.11

LHR-WTS-DP-02                                        LHR-BOD-DP-01                     LHR-BOD-DP-01

(CBXCMGRSUB01 - Node ID 14)           (BODCMGRSUB01 - Node ID 10) (BODCMGRSUB01 - Node ID 10)

 

File SDL014_100_000123.zip is taken from CBXCMGRSUB01 -(Node ID 14) where I can see the originating call from 808226

File SDL010_100_001287.zip is taken from BODCMGRSUB01 - (Node ID 10) which I can see the transfer call and can see a SIP 'BYE@ message, but not sure which party is originating this.

In file SDL010_100_001289.zip which is also taken from BOCMGRSUB01 - (Node ID 10) - I can see a SIP REGISTER message from 51086, which was already registered with Call Manager, so doesn't look correct to me, but I could be wrong.

 

I then changed the device pool of extension 808226 to LHR-BOD-DP-01 to match the other 2 parties, remade the same call and the call transferred OK.

 

The files SDL010_100_001332.zip and SDL010_100_0001333.zip both from BODCMGRSUB01 (Node ID 10) show the successful call.

 

Thanks,

Peter

 

 

Hi Brian,

 

In the file – ‘287’ – I See the following which looks like the SIP client telling the calling party who to contact to complete the call before it drops:-

 

83725382.001 |15:00:47.320 |AppInfo  |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 1070 from 161.2.123.189:[5060]:

[1300795,NET]

REFER sip:808226@10.203.105.50:5060 SIP/2.0

From: <sip:51086@10.203.105.50>;tag=9743e58-bd7b02a1-13c4-6006-33abc-2c83c6dd-33abc

To: <sip:808226@10.203.105.50>;tag=319306~7c938c6e-32f2-44ac-9040-f2a8f81ad238-236432618

Call-ID: f0681c00-37a10e81-ceab-3269cb0a@10.203.105.50

CSeq: 3 REFER

Via: SIP/2.0/UDP 161.2.123.189:5060;rport;branch=z9hG4bK-33aca-c9da535-7e754376-9594a30

Refer-To: <sip:55152390@10.203.105.50:5060?Replaces=9a907e0-bd7b02a1-13c4-6006-33ac5-409f617c-33ac5%3Bto-tag%3D319311~7c938c6e-32f2-44ac-9040-f2a8f81ad238-172070608%3Bfrom-tag%3D9744380-bd7b02a1-13c4-6006-33ac5-4f0fcada-33ac5>

Referred-By: <sip:51081@10.203.105.50:5060>

Max-Forwards: 70

Supported: replaces

User-Agent: TPSWAVE-SIP 1.0.0.1

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

Contact: <sip:51081@161.2.123.189:5060>

Authorization: Digest username="DEMOHACDISP",realm="ccmsipline",nonce="StW99ElFAJnU1oFpTQnZ8mNJk6UXk/No",uri="sip:808226@10.203.105.50:5060",response="9559d4ab31dbc4b88c2d962fd0b64035",algorithm=MD5

Content-Length: 0

 

 

I.e. the ‘Referred-By’ and ‘Contact’ fields show 51081. This is another SIP client, but not involved in the call at all, although that is one of the clients that we have been using for testing. In fact the Contact field shows the IP address of 51086.

 

This is wrong surely?

 

Thanks,

 

Peter

Hi Brian,

 

Thank you for all of your help on this.

 

I have passed your findings onto the supplier of the softphone software and await their reply

So the problem here is that the SIP endpoint is sending the BYE too early.

 

It needs to send the Refer, get the Accepted message, then wait for the Notify with "Content-Type: message/sipfrag;version=2.0" of "SIP/2.0 200 OK".  This is in accordance with RFC 3515 (http://www.ietf.org/rfc/rfc3515.txt).

 

The only reason the working scenario works is that all the processes live on the same node resulting in very fast processing of the Refer.  It's able to send out the 100 Trying Notify message:

84376553.001 |15:30:45.016 |AppInfo  |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 161.2.123.189:[5060]:
[1302060,NET]
NOTIFY sip:51081@161.2.123.189:5060 SIP/2.0
Via: SIP/2.0/UDP 10.203.105.50:5060;branch=z9hG4bK2587c4894ac04
From: <sip:808226@10.203.105.50>;tag=319593~7c938c6e-32f2-44ac-9040-f2a8f81ad238-172074450
To: <sip:51086@10.203.105.50>;tag=974eda8-bd7b02a1-13c4-6006-341c2-754e034c-341c2
Call-ID: 20b1b980-37a11588-cee1-3269cb0a@10.203.105.50
CSeq: 102 NOTIFY
Max-Forwards: 70
Date: Mon, 19 May 2014 14:30:45 GMT
User-Agent: Cisco-CUCM9.1
Event: refer
Subscription-State: active;expires=60
Contact: <sip:808226@10.203.105.50:5060>
Content-Type: message/sipfrag;version=2.0
Content-Length: 20

SIP/2.0 100 Trying

 

It still doesn't allow time for the 200 OK Notify message but it gives just enough time for the TransferManager process to finish the transfer.

 

In the nonworking scenario, the extra delay sending messages between nodes results in TransferManager not completing the transfer before the incoming BYE from the SIP Phone resulting in the call to the first party being disconnected.

 

It looks like the WAVE Softphone SIP client is not following the correct RFC specification for these transfers and needs to be updated.  You should let the maker of the software know about this.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: