[CUCM] Remote ip address in hardware conferences with external numbers

[AlbertoVilas]

Hi,

We have a 10.5 CUCM cluster with a Pub and a Sub. We also have hardware conferences resources in a 2811 ISR.

Conferences resources are registered to Subscriber, but when we make a conference with external numbers, the remote IP address shown is the IP of the Publisher:

PUB IP: 172.18.0.12

SUB IP: 172.18.4.12

2821 configuration:

sccp local Port-channel1.10
sccp ccm 172.18.4.12 identifier 1 priority 1 version 7.0
sccp ccm 172.18.0.12 identifier 2 priority 2 version 7.0
sccp
!
sccp ccm group 1
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 100 register CFB_GW-1
!
dspfarm profile 100 conference
codec g729br8
codec g729r8
codec g729abr8
codec g729ar8
codec g711alaw
codec g711ulaw
maximum sessions 4
associate application SCCP

CFB config on CUCM:

	Conference Bridge Name	Description	Device Pool	Status	IPv4 Address
	CFB_GW-1	CFB_GW-1	DP_SITE1	Registered with CUCMSUB	172.18.4.20

Show sccp conn output for a conference between an IP phone an 2 external numbers:

gw-voz#sh sccp connections
sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx

33558458 33701607 conf sendrecv g729b 17302 26490 172.18.0.12
33558458 33701603 conf sendrecv g729b 16736 21988 172.18.7.29
33558458 33701602 conf sendrecv g729b 16780 26486 172.18.0.12

Total number of active session(s) 1, and connection(s) 3

The Route List for the Route Pattern of these call is also registered in SUB

We need that the remote IP address in this scenario will be 172.18.4.12 to avoid network problems.

Anyone know why remote IP address is the PUB one and not the SUB one?

Thanks and regards,

Alberto Vilas

[Steven Landon]

what server is the trunk/gateway the external callers are coming in on registered to?

[AlbertoVilas]

Hi Steven,

We have a SIP Trunk to our service provider for these external calls.

The IP Phone initates an ad-hoc conference to the PSTN numbers.

Thanks and regards,

Alberto Vilas

[Steven Landon]

but the outgoing SIP trunk. what CUCM server is that trunk registered to?

[AlbertoVilas]

Hi Steven,

This particular SIP Trunk has CM Group where SUB is the primary node (in the configuration I don´t know how to see where this SIP trunk is registered to)

SIP Trunk has the Run On All Active Unified CM Nodes parameter enabled...

Thansk and regards,

[Steven Landon]

1. I assume the call manager service is activated and running on the Publisher?

2. the gateway that terminates the SIP trunk, is there a dial peer that points to the Publisher? is it the preferred dial peer?

[AlbertoVilas]

1. I assume the call manager service is activated and running on the Publisher?

Yes, it´s activated and running

2. the gateway that terminates the SIP trunk, is there a dial peer that points to the Publisher? is it the preferred dial peer?

We have a direct SIP Trunk between CUCM and service provider SBC

Thanks and regards,

Alberto Vilas

[Steven Landon]

Most likely, the carrier is using the Pub as it's primary peer.

You need to re-examine why this is a problem. You should not have "routing issues" based on which CUCM server terminates a call.

That is a bad design and will continuously cause issues for you.

[AlbertoVilas]

Hi Steven,

Ok, I´ll check it with service provider.

The routing issues are because our SIP Trunk is routed throught 2 CPEs, each one on one of our main sites:

Publisher is on site A and Subscriber is on side B.

If call is made for a phone in site B it goes for the CPE of side B, and Service Provider knows that the IP of this phone is reachable through this CPE.

But for these conferences as far as the remote IP is the one of the PUB, outbound audio goes through a CPE an inbound audio goes through the other, so we have audio issues.

Thanks and regarsd,

Alberto Vilas

[Ayodeji Okanlawon]

Can you do a test call and attach the CUCM logs. We can see from the logs why media is terminating on the publisher. Please include the call details..

ie Time of call

Called number, calling and conferenced number.

[AlbertoVilas]

Hi Ayodeye,

I´ve just make a test:

Timestamp: 13:56:44 GMT+1

Calling number: 32112 (DDI:986916491)

Called number: 654912964

Conferenced: 10002

CUCM PUB IP: 172.18.0.12

CUCM SUB IP: 172.18.4.12

Conference GW IP: 172.18.4.20

SIP TRUNK SBC IPs: 10.101.3.52 & 10.101.3.60

And the output of "show sccp conn" on the Conference GW:

gw-voz-vigo#sh sccp connections
sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx

33558459 33705214 conf sendrecv g729b 16674 29330 172.18.0.12
33558459 33705210 conf sendrecv g729b 17454 27690 172.18.7.29
33558459 33705209 conf sendrecv g729b 18004 29326 172.18.0.12

Thanks for your answer.

Alberto Vilas

[Ayodeji Okanlawon]

Hi,

From the logs an MTP is getting selected when CUCM tried to connect the called number and "conferenced" number to the conference bridge

+++ CUCM attempted t co connect the called number to bridge ++

CI=39861557 Fqdn=pi=0si1 Cgpn=tn=0npi=0ti=1nd=0654912964pi=0si1 DialedNum=ti=1nd=b00205414002pi=0si1 requestID=0 DigitAnalysisComplexity=0 CallingUser= IgnoreIntercept=0
30837655.001 |13:57:18.860 |AppInfo  |Digit Analysis: star_DaReq: daReq.partitionSearchSpace(f63b136c-b935-dfda-e719-49c2a822929b), filteredPartitionSearchSpaceString(Directory URI:PT_INTERNA), partitionSearchSpaceString(Directory URI:PT_INTERNA)

30837655.008 |13:57:18.860 |AppInfo  ||PretransformCallingPartyNumber=0654912964
|CallingPartyNumber=0654912964
|DialingPartition=
|DialingPattern=b00205414002
|FullyQualifiedCalledPartyNumber=b00205414002

---

The reason that media is going to CUCM is because when CUCM tried to connect called user to CFB, it detected a DTMF mismatch

30837736.008 |13:57:18.863 |AppInfo  |DET-MediaManager-(117310)::isMTPNeededForMismatchOrConfig, MTPNeededDueToDTMFCapMismatch(2833/OOB) mtpinsertionReason=1 dtmfMTPSide=1

30837736.008 |13:57:18.863 |AppInfo  |DET-MediaManager-(117310)::isMTPNeededForMismatchOrConfig, MTPNeededDueToDTMFCapMismatch(2833/OOB) mtpinsertionReason=1 dtmfMTPSide=1
30837736.009 |13:57:18.863 |AppInfo  |DET-MediaManager-(117310)::isMTPNeededForDTMF, isMTPNeeded for DTMF inection from OOB to 2833 party1MTPNeed=0 party1MTPNeed=0 mtpinsertionReason=1
30837736.010 |13:57:18.863 |AppInfo  |DET-MediaManager-(117310)::isMTPNeededForDTMFInjectionFromOOBTo2833 - MTPInsertionReason=1 DTMFSide=1 Party1XferMode=16 Party2XferMode=8 Party 1[DTMFConfig=3 DTMFMethod=2 wantDTMFReception=1 DTMFReception=0 MTPNeedForDTMFInject=0] Party 2[DTMFConfig=1 DTMFMethod=1 wantDTMFReception=1 DTMFReception=0 MTPNeedForDTMFInject=0]

Party 1[DTMFConfig=3 (prefer 2833) DTMFMethod=2 ( RFC2833)

Party 2[DTMFConfig=1 ( best effort) DTMFMethod=1(OOB)

To resolve this, you can configure a software MTP on your voice gateway or just use your existing xcoder ( Verify that the transcoder supports RFC2833 to OOB DTMF conversion). You should then ensure that you remove the software MTPs ( MTP_2, etc) from the default MRG. Assign then to a MRG. Then on your MRGL, add the hardware MRG as the first and you can leave the software one as backup. That way when an MTP device is needed, your ios transcoder will be selected. You should also ensure that your xcoder supports G729annexb,a s this is the codec you are negotiating for the call.

You can verify by this by doing a sh sccp on the gateway. Something similar to this output

Transcoding Oper State: ACTIVE_IN_PROGRESS - Cause Code: NONE

Active Call Manager: NONE

TCP Link Status: NOT_CONNECTED, Profile Identifier: 1

Reported Max Streams: 10, Reported Max OOS Streams: 0

Supported Codec: g711alaw, Maximum Packetization Period: 30

Supported Codec: g722r64, Maximum Packetization Period: 30

Supported Codec: g711ulaw, Maximum Packetization Period: 30

Supported Codec: g729ar8, Maximum Packetization Period: 60

Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30

Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30

Supported Codec: inband-dtmf to rfc2833 conversion, Maximum Packetization Period: 30

If your xcoder doesnt support rfc2833 to inband-dtmf, then configure a software MTP on your ios gateway and ensure you add "codec passthrough as one of the codecs "

Lastly you can change your DTMF preference on your sip trunk to use no preference

[AlbertoVilas]

Hi Ayodeji,

Thanks for your answer. 

I´ve create an MTP resource in the gateway and I´ve include it in the MRG of the phone which makes the conference, but I´m still seeing that the remote address for the externals in the conference is the IP address of the PUB.

Maybe it´s also necessary to change the MRGL of the SIP Trunk? 

SIP Trunk has an MRGL wich has the software MTP of the PUB.

On other hand, due this is related to DTMF mismatch, could be any way to change the DTMF method in the media resources gateway?, so no MTP will be required...

Thanks and regards,

Alberto Vilas

[Ayodeji Okanlawon]

The MRGL that is beign used is this and the MTP devices are shown below

MRG_SATEC

MTPG729GW2

MTPG729bGW2

MTP_2

MTP_4

You need to ensure that you have codec pass-through is configured on your IOS MTP device for CUCM to select it.CUCM prefers pass-through MTP to any other MTP.  CUCM will select software MTP over ios MTP because it supports pass-through. To ensure ios MTP is selected configure codec pass-through on it.

The reason you gave DTMF mismatch is that your conference bridge is a SCCP device and your SIP Trunk uses on RFC2833. You can try and change the DTMF preference on the SIP trunk to no preference

[AlbertoVilas]

Hi Ayodeji,

Thanks for your answer. i´ll perform these changes in a maintenance windows.

Thanks and regards,

Alberto Vilas