daily @Sydney TAC

Blog

Apr 19, 2011 3:30 AM
Apr 19th, 2011

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

Welcome to 'daily @Sydney TAC' blog. Every day, we receive some interesting and challenging service requests. In some cases, it may get resolved by brain storming, a bit research. But in some cases, it requires lab testing, developer engagement.

Often, we need to tune some configuration when integrated with multiple Cisco component or 3rd party products.

Hope you will be benefited from here. Also please leave your comments

Regards

-Abu

Average Rating: 4.4 (5 ratings)

Comments

Abu Hadee Wed, 04/20/2011 - 07:41

Some CUBE related issue that I've worked on today.

1st issue:

-------------

By default, CUBE use codec filter when it negotiate codec on eiter side of the call leg.

Lets say, topology is

CUCM----SIP-----CUBE------SIP---- Service Provider

CUBE dial-peers are confifgured with codec class with G711ulaw and G729r8. But CUCM is configured for early offer wit G711. Now, when CUCM sends sip invites to CUBE, it only offers G711. So, when cube forwards the call to service provider, it will only send G711 in SIP offer though you have dial-peer with codec class. This is due to codec filtering by cube. Because there is no point of sending other codec if it can't be used.

Now, if you want to override this feature and want to send all codec to provider no matter what is coming in from CUCM, you can do it by following command

dial-peer voice 1001 voip

Description Dial-peer to Service Provider

voice-class codec 1 offer-all

!

The purpose of this command is to send all the codec defined in codec class no matter what is coming in other call leg.

But this command deosn't work itself. You need to have transcoding resource registered to CUBE (as CME). If  the cube does not have any transcoding resources to itself, offer-all command would not work. This is failsafe mechanism. Because if provider chooses G729,which cube can not afford becuase other call leg is G711.

2nd Issue:

--------------

Refer pass throug.

With the new feature of CUBE, if CUBE receives REFER message, it will pass the refer message on the other leg. But if we want to stop CUBE forwarding the REFER, instead look its own dial-peer to match, then following commands need to be configured

voice service voip
no supplementary-service sip refer
sip-ua
xfer target dial-peer
!

The supplementary service will stop the refer to passthrough. And xfer target command will force CUBE to look only user part of the refer-to message, not the host part.

---

Hope this helps.

Good night all.

Abu Hadee Sat, 04/30/2011 - 01:28 (reply to Abu Hadee)

Hi All,

Not many things happening during the easter break. So nothing more to add so far.

Take care all.

- abu

sumimanc Mon, 05/16/2011 - 03:06 (reply to felixiipc)

Hi Abu,

Great work I must say.Keep them coming.

Very useful and pleasure to work with such an extremly knowledgable escalation engineer like you

Regards,

sumit

Abu Hadee Mon, 05/16/2011 - 03:37

When PSTN calls forwarded to Voicemail, it takes 5s or more before hearing prompts:

PSTN----T1-----CME/CUE---IP Phone

When call comes from PSTN to ring CME Phone, no matter if there is callfwd all or call-fwd noan, in either case, when call is forwarded to CUE, there is 5s silence before the prompt from CUE is heard.

While looking at the debug, after the call is being diverted,

May 16 05:51:47.923: //66/6923FE0D8015/CCAPI/ccGetTBCTCap:

   TGRM TBCT Enabled; TBCT Capability=0

May 16 05:51:47.923: //66/6923FE0D8015/CCAPI/ccCallFacility:

   Call Id=66

May 16 05:51:47.923: //66/6923FE0D8015/VTSP:(0/0/1:15):2:1:1/vtsp_process_event: 

   [state:S_ALERTING, event:E_CC_SERVICE_MSG]

May 16 05:51:47.923: //66/6923FE0D8015/VTSP:(0/0/1:15):2:1:1/act_service_msg_down:

May 16 05:51:47.923: //66/6923FE0D8015/VTSP:(0/0/1:15):2:1:1/vtsp_timer_stop: 

   Timer Stop Time=456777

May 16 05:51:52.923: //66/6923FE0D8015/CCAPI/ccGetTBCTCap:

   TGRM TBCT Enabled; TBCT Capability=0

May 16 05:51:52.923: //66/6923FE0D8015/CCAPI/ccCallSetupRequest:

   Destination=, Calling IE Present=TRUE, Mode=0,

   Outgoing Dial-peer=8999, Params=0x440C0EC8, Progress Indication=NULL(0)

May 16 05:51:52.923: //66/6923FE0D8015/CCAPI/ccCheckClipClir:

From the logs, it is clear that ccGetTBCTCap function is taking long time and that is causing the problem. Now ccGetTBCTCap function is for "Two B Channel Call Tranfer" and it is usually a function of QSIG.

We've also checked that if the call from PSTN goes directly to CUE or IP Phone calling another IP Phone and forwarded to CUE, no delay is experienced.

After reviewing the config, we found that following is configured

voice service pots

supplementary-service qsig call-forward

Once the above is removed, there is no delay when the call is forwarded.
Abu Hadee Thu, 05/19/2011 - 23:33

Load Balancing of Call through dial-peer

Lets condsider the following configuration on Voice Gateway
dial-peer voice 1001 voip
preference 1
destination-pattern 5600
session protocol sipv2
session target ipv4:10.66.75.237
dtmf-relay rtp-nte
codec g711ulaw
no vad

dial-peer voice 1002 voip
preference 1
destination-pattern 5600
session protocol sipv2
session target ipv4:10.66.75.240
dtmf-relay rtp-nte
codec g711ulaw
no vad


One may assume that voice gateway will load balance the call to 5600  to 10.66.75.237 and 10.66.75.240 in round robin fashion. The gateway will do load balance, but it's not round robin. Gateway will randomly choose a dial-peer. Due to randomness of the dial-peer selection, at one point, it may send more calls on one dial-peer then the other.

AS5400XM-3(config)#dial-peer hunt ?
  <0-7>  Dial-peer hunting choices, listed in hunting order within each choice:
  0 - Longest match in phone number, explicit preference, random selection.
  1 - Longest match in phone number, explicit preference, least recent use.
  2 - Explicit preference, longest match in phone number, random selection.
  3 - Explicit preference, longest match in phone number, least recent use.
  4 - Least recent use, longest match in phone number, explicit preference.
  5 - Least recent use, explicit preference, longest match in phone number.
  6 - Random selection.
  7 - Least recent use.

The default hunt mechanism is 0 which is , longtest match, explicit preference, then random selection. So, it wont be like 1 call to dial-peer 1001 and next call to 1002. Over long period of time, both dial-peer may be used in equally, but not a certain instance.

To make round robin to work you need to configure
dial-peer hunt 1
This will cause the gateway to use least use dial-peer, which will be round robin.

Abu Hadee Tue, 06/14/2011 - 23:32

One of the issue that we worked on where IP Phone not able to get calls from SIP Provider via CUBE

Topology:

PSTN (SIP provider)------sip----CUBE------sip-------CUCM

While  looking at the cube debug, we can see that CUBE is receiving call from  SIP provider and forwarding the call to CUCM. But looking at CUCM logs,  we dont see any call hitting CUCM at all. Checked CUCM sdi and sdl logs,  but not a single event as if CUBE is not sending any call at all. But  from CUBE logs, it does show that it sending call to CUCM and getting  response.

That's a bit of puzzling as to what is happening there. Then we did packet capture on the CUBE using EPC.

From  the packet capture we found that for the call that we think CUBE is  sending to CUCM, it is actually sending to provider again instead of  cucm though sip debug on cube shows it is sending to cucm.

So, we looked at the CUBE configuration again, then found that following command (similar) is configured:

voice service voip

   sip

     outbound-proxy dns:proxy.abc.com

!

Once we remove the command all worked.

Now,  it makes sens why we were seeing the debug on CUBE showing call is  being sent to CUCM, where is it was originally sent to SIP Provider.

lets consider following configuration

voice service voip

  sip

    outbound-proxy ipv4:10.1.1.1

!

dial-peer voice 100 voip

destination-pattern 1234

session target ipv4:20.1.1.1

session protocol sipv2

codec g711ulaw

!

Now, if the called number is 1234, CUBE will match dial-peer  1000. So, the SIP header will be made as per the dial-peer configuration  like request-uri, and to header. But the actual SIP Message will be  sent to 10.1.1.1

Its better to use outbound-proxy  comamnd is configured per dial-peer instead of global. Even if you  configure outbound proxy on global, make sure you've configure "no  voice-class sip outbound-proxy" under the dial-peer those point to cucm  or other gateway that doesn't need proxy.

Thanks

-abu

miguel.marin.z Thu, 06/30/2011 - 08:29

Hi

I have to connect an ANALOG PBX with my UC560 and i dont know how i can to put the voice port 0/0/0 in standBy (wait tones from analog pbx).

Thanks!

miguel.marin.z Tue, 07/05/2011 - 11:29

Hi

I dont know how i can configure my Voice Port 0/0/0, i have to put this port on standby for a incoming call.

Thanks

Abu Hadee Tue, 07/12/2011 - 00:47

Hi All,

We had an interesting issue regarding REFER on CUBE and CUCM. I like to share this.

Topology:

Phone---CUCM----SIP-------CUBE-----SIP------IVR(3rd party)

CUCM:10.66.81.91

CUBE:10.66.75.245

IVR(CME):10.66.81.21

Call Flow:

1. IP Phone Calls IVR via CUBE

2. IVR transfer the call to another extention

3. IVR sends REFER to CUBE

4. CUBE sends the REFER to CUCM

5. CUCM rejects the REFER (due to refer-to header host ip)

The REFER that comes CUBE

-------------------------

Jul 12 06:47:54.776: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

REFER sip:2001@10.66.75.245:5060 SIP/2.0

Via: SIP/2.0/UDP 10.66.81.21:5060;branch=z9hG4bK1C411A86

From: <sip:4006@10.66.81.21>;tag=CCDE86B4-22A1

To: <sip:2001@10.66.75.245>;tag=C7E6E86C-1800

Call-ID: B158C21E-AB8911E0-AD6BF2B6-3BEDB301@10.66.75.245

CSeq: 102 REFER

Max-Forwards: 70

Contact: <sip:4006@10.66.81.21:5060>

User-Agent: Cisco-SIPGateway/IOS-12.x

Timestamp: 1310454318

Refer-To: sip:4007@10.66.81.21

Referred-By: <sip:4006@10.66.81.21>

Content-Length: 0

CUBE sends REFER to CUCM

------------------------

Jul 12 06:47:54.780: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

REFER sip:2001@10.66.81.91:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.66.75.245:5060;branch=z9hG4bK21DF1BC1

From: <sip:4006@10.66.75.245>;tag=C7E6E888-1199

To: <sip:2001@10.66.81.91>;tag=ec4db27b-2813-452d-830c-3f4920b776f7-26616942

Call-ID: 487e6000-e1b1f229-14-5b51420a@10.66.81.91

CSeq: 102 REFER

Max-Forwards: 70

Contact: <sip:4006@10.66.75.245:5060;transport=tcp>

User-Agent: Cisco-SIPGateway/IOS-12.x

Timestamp: 1310453274

Refer-To: sip:4007@10.66.75.245

Referred-By: <sip:4006@10.66.75.245>

Content-Length: 0

If you look at the Refer-To header, the host portion is CUBE's own IP Address. Now, when CUCM receives this REFER, it will check with it's own host

07/12/2011 00:05:18.440 CCM|CMSIPUtility: isIPAddrOrHostInMyCluster no match found for 10.66.75.245 in the cluster host/ip cache|<CLID::StandAloneCluster><NID::pub><LVL::Detailed><MASK::ffffff>

07/12/2011 00:05:18.440 CCM|CMSIPUtility::isOurTopLevelDomain TLD is  and host is 10.66.75.245|<CLID::StandAloneCluster><NID::pub><LVL::Detailed><MASK::ffffff>

07/12/2011 00:05:18.440 CCM|CMSIPUtility::isOurClusterFQDNName TLD is  and host is 10.66.75.245|<CLID::StandAloneCluster><NID::pub><LVL::Detailed><MASK::ffffff>

07/12/2011 00:05:18.440 CCM|CMSIPUtility: isMyIpAddrOrMyHostName Node ip or host name did not match 10.66.75.245 |<CLID::StandAloneCluster><NID::pub><LVL::Detailed><MASK::ffffff>

Since CUCM didn't think the REFER call is for itself, it will Notify CUBE with "404 Not found" for the REFER

07/12/2011 00:05:18.449 CCM|//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.66.75.245 on port 5060 index 6

NOTIFY sip:4006@10.66.75.245:5060;transport=tcp SIP/2.0

Date: Tue, 12 Jul 2011 07:05:18 GMT

From: <sip:2001@10.66.81.91>;tag=ec4db27b-2813-452d-830c-3f4920b776f7-26616942

P-Asserted-Identity: <sip:2001@10.66.81.91>

Event: refer

Content-Length: 23

User-Agent: Cisco-CUCM7.1

To: <sip:4006@10.66.75.245>;tag=C7E6E888-1199

Contact: <sip:2001@10.66.81.91:5060;transport=tcp>

Content-Type: message/sipfrag;version=2.0

Call-ID: 487e6000-e1b1f229-14-5b51420a@10.66.81.91

Subscription-State: terminated

Via: SIP/2.0/TCP 10.66.81.91:5060;branch=z9hG4bK4e4ce628f0

CSeq: 104 NOTIFY

Max-Forwards: 70

SIP/2.0 404 Not Found

Solution:

To get around this problem, the easy solution is configuring SIP Profile on CUBE and apply on Incoming dial-peer

voice class sip-profiles 10

request REFER sip-header Refer-To modify "10.66.75.245" "10.66.81.91"

dial-peer voice 4006 voip

destination-pattern 400.

session protocol sipv2

session target ipv4:10.66.81.21

incoming called-number 400.

voice-class sip profiles 10

codec g711ulaw

no vad

!

Now, when REFER is recevied from IVR and sent to CUCM, it will look like

Jul 12 06:52:20.612: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

REFER sip:2001@10.66.75.245:5060 SIP/2.0

Via: SIP/2.0/UDP 10.66.81.21:5060;branch=z9hG4bK1C441E33

From: <sip:4006@10.66.81.21>;tag=CCE293C4-207E

To: <sip:2001@10.66.75.245>;tag=C7EAF580-1235

Call-ID: 4F979FF8-AB8A11E0-AD72F2B6-3BEDB301@10.66.75.245

CSeq: 102 REFER

Max-Forwards: 70

Contact: <sip:4006@10.66.81.21:5060>

User-Agent: Cisco-SIPGateway/IOS-12.x

Timestamp: 1310454584

Refer-To: sip:4007@10.66.81.21

Referred-By: <sip:4006@10.66.81.21>

Content-Length: 0

Jul 12 06:52:20.616: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

REFER sip:2001@10.66.81.91:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.66.75.245:5060;branch=z9hG4bK21E726C8

From: <sip:4006@10.66.75.245>;tag=C7EAF5A0-196D

To: <sip:2001@10.66.81.91>;tag=ec4db27b-2813-452d-830c-3f4920b776f7-26616946

Call-ID: e6722a80-e1b1f332-15-5b51420a@10.66.81.91

CSeq: 102 REFER

Max-Forwards: 70

Contact: <sip:4006@10.66.75.245:5060;transport=tcp>

User-Agent: Cisco-SIPGateway/IOS-12.x

Timestamp: 1310453540

Refer-To: sip:4007@10.66.81.91

Referred-By: <sip:4006@10.66.75.245>

Content-Length: 0

Since, Refer-To header points to CUCM IP Addres, it wont have any problem accepting the call and do Digit analysis.

The above configuration is valid only if the call comes from one particular call manager. What if there is multiple call manager. Lets say, if the call comes from 10.66.81.92, the call will fail again. Because, this configuration will change the refer to 10.66.81.91, and 10.66.81.92 will not recognise it as its own.

This can be resolve in multiple way. You can have FQDN as top level domain, and change the Refer-To header as per that. That way, no matter who gets the REFER will accept it and route accordingly.

Other options to use the latest SIP feature to match dial-peer as per the source. So, we can have dial-peer 4001 matched as incoming from 10.66.81.91 and dial-peer 4002 matched as incoming call from 10.66.81.92. Configure the sip profile to change the refer-to header accordingly.

I'll add another configuration on this later.

Thanks

-abu

prvelpul Wed, 07/13/2011 - 03:35

This blog is really excellent Abu, I am privileged to be a part of your technical expertise

Abu Hadee Fri, 07/29/2011 - 07:03

We had another interesting FAX issue which involves a 3rd party fax server. Fax from and to fax server from PSTN fails.

Here is topology diagram:

T1 PRI is MGCP Controlled. T1 PRI connected to Fax Server is h323 controlled.

After troubleshooting, we found that the fax is failing due very classic clocking issue. The Clock wasn't configured properly between the Fax Server and Voice GW.

Since the GW has T1 connected to Telco. It is kind of a mandatory that Clocking should be configured on that T1 is line. Because provider will always be clocking provider. Now, the issue was that it was configured such Fax Server was providing clock back to GW as well. Now, GW can not handle two clocking source. There can only be 1 clocking source.

So, we've made the "clock source" on  other T1 connected to Fax Server as internal so that it provides clocking to fax server. But we still kept seeing clock slips on fax server T1. This meant that fax server needs to be configured to take clock from the Router. This is where we struggle to configure. It was brooktroute T1 interface card on the fax server. The T1 clocking configuration may seem a bit confusing on that which took us a bit of time for realize how it needs to be configured. We had to go through the help pages on Brooktroute T1 configuration.

Here is what is configured.

controller T1 0/2/0

description Connected to Telco

cablelength long 0db

pri-group timeslots 1-24 service mgcp

!

controller T1 0/2/1

description Connected to Fax Server

clock source internal

cablelength long 0db

pri-group timeslots 1-8,24

network-clock-participate wic 0

network-clock-participate wic 2

network-clock-select 1 T1 0/2/0

! T1 connected to Telco should be clock provider to internal bus and DSP

No drama in Voice Gateway configuration. Here is the output of Brooktroute t1 card clock configuration.

Under the "Clock Setting" tab, "Clock mode" needs to be "master". "Clock Source" needs to be the Port on fax server connected to Voice Gateway. Our case, it was Port A. Most important, "Compatibility" needs to be MVIP.

After configuring all these, restarting the card, we stop seeing any clock slips on Cisco Router. Once clock slips are gone, fax started working without any problem.

H.100 configuration is not important here as those configs are required when you have multiple cards.

Here are few sample debug and show command output

Non Working Scenario:

C2821-V-MPLS(config-controller)#do sh controller t1 0/2/1

T1 0/2/1 is up.

  Applique type is Channelized T1

  Cablelength is long 0db

  No alarms detected.

  alarm-trigger is not set

  Soaking time: 3, Clearance time: 10

  AIS State:Clear  LOS State:Clear  LOF State:Clear

  Version info Firmware: 20071011, FPGA: 13, spm_count = 0

  Framing is ESF, Line Code is B8ZS, Clock Source is Internal.

  CRC Threshold is 320. Reported from firmware  is 320.

  Data in current interval (247 seconds elapsed):

     21761 Line Code Violations, 26 Path Code Violations

     220 Slip Secs, 0 Fr Loss Secs, 6 Line Err Secs, 2 Degraded Mins

     218 Errored Secs, 4 Bursty Err Secs, 3 Severely Err Secs, 13 Unavail Secs

.Jul 27 01:36:42: 0/2/1:23 (306)  12779318 fr-entered=10(ms)

.Jul 27 01:36:42: 0/2/0:23 (303)  12779327 fr-entered=10(ms)

    timestamp=12780328 fr-msg-det CSI

    timestamp=12780647 fr-msg-tx CSI

    timestamp=12781018 fr-msg-det DIS

    timestamp=12781337 fr-msg-tx DIS

    timestamp=12785848 fr-msg-det CSI

    timestamp=12786167 fr-msg-tx CSI

    timestamp=12786538 fr-msg-det DIS

    timestamp=12786857 fr-msg-tx DIS

    timestamp=12792968 fr-msg-det CSI

    timestamp=12793287 fr-msg-tx CSI

    timestamp=12793668 fr-msg-det DIS

    timestamp=12794287 fr-msg-tx DIS

    timestamp=12800688 fr-msg-det CSI

    timestamp=12801007 fr-msg-tx CSI

    timestamp=12801317 FR_BAD_CRC_LS_DATA 0x0 bytes

    timestamp=12811358 fr-msg-det CSI

    timestamp=12811677 fr-msg-tx CSI

    timestamp=12812048 fr-msg-det DIS

    timestamp=12812367 fr-msg-tx DIS

Working Scenario:

RC2821-V-MPLS#sh controller t1 0/2/1

T1 0/2/1 is up.

  Applique type is Channelized T1

  Cablelength is long 0db

  No alarms detected.

  alarm-trigger is not set

  Soaking time: 3, Clearance time: 10

  AIS State:Clear  LOS State:Clear  LOF State:Clear

  Version info Firmware: 20071011, FPGA: 13, spm_count = 0

  Framing is ESF, Line Code is B8ZS, Clock Source is Internal.

  CRC Threshold is 320. Reported from firmware  is 320.

  Data in current interval (98 seconds elapsed):

     0 Line Code Violations, 0 Path Code Violations

     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Jul 27 02:03:59: 0/2/1:23 (321)  14418167 fr-entered=10(ms)

Jul 27 02:03:59: 0/2/0:23 (318)  14418179 fr-entered=10(ms)

    timestamp=14419177 fr-msg-det CSI

    timestamp=14419499 fr-msg-tx CSI

    timestamp=14419877 fr-msg-det DIS

    timestamp=14420189 fr-msg-tx DIS

    timestamp=14422759 fr-msg-det TSI

    timestamp=14422877 fr-msg-tx TSI

    timestamp=14423459 fr-msg-det DCS

    timestamp=14423567 fr-msg-tx DCS

    timestamp=14440829 fr-msg-det EOP

    timestamp=14440947 fr-msg-tx EOP

    timestamp=14442557 fr-msg-det MCF

    timestamp=14442879 fr-msg-tx MCF

    timestamp=14444769 fr-msg-det DCN

    timestamp=14444887 fr-msg-tx DCN

Complete GW configuration for T.38 singalling based.

controller T1 0/2/0

cablelength long 0db

pri-group timeslots 1-24 service mgcp

!

controller T1 0/2/1

clock source internal

cablelength long 0db

pri-group timeslots 1-8,24

!

ccm-manager fallback-mgcp

ccm-manager redundant-host 172.16.20.10

ccm-manager mgcp

no ccm-manager fax protocol cisco

ccm-manager music-on-hold

ccm-manager config server 172.16.20.10 172.16.20.11

ccm-manager config

!

mgcp

mgcp call-agent 172.16.20.11 2427 service-type mgcp version 0.1

mgcp rtp unreachable timeout 1000 action notify

mgcp package-capability rtp-package

mgcp package-capability sst-package

mgcp package-capability pre-package

mgcp default-package fxr-package

no mgcp package-capability res-package

no mgcp timer receive-rtcp

mgcp sdp simple

mgcp rtp payload-type g726r16 static

mgcp bind control source-interface GigabitEthernet0/0

mgcp bind media source-interface GigabitEthernet0/0

dial-peer voice 1 voip

translation-profile outgoing FAX

preference 1

destination-pattern 9[2-9]......

voice-class codec 1

voice-class h323 1

session target ipv4:172.16.20.11

dtmf-relay h245-alphanumeric

!

dial-peer voice 2 voip

translation-profile outgoing FAX

preference 2

destination-pattern 9[2-9]......

voice-class codec 1

voice-class h323 1

session target ipv4:172.16.20.10

dtmf-relay h245-alphanumeric

dial-peer voice 999 voip

incoming called-number .

codec g711ulaw

fax-relay ecm disable

fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback none

!

dial-peer voice 801 pots

description To Fax Server

destination-pattern ^....$

port 0/2/1:23

forward-digits 4

!

Abu Hadee Thu, 08/18/2011 - 02:08

Another update on a Privacy related issue.

Topology:

IP Phone-----CUCM-----SIP-----VoiceGW----ISDN----Telco

When call is made from IP Phone to outside, the privacy is set to full. This can be seen on ISDN side, the GW strips the privacy setting and send it as normal call.

From the SIP Debug received by Voice GW

Received:

INVITE sip:+2223335555@10.40.42.5:5060 SIP/2.0

Via: SIP/2.0/UDP 10.1.1.33:5060;branch=z9hG4bKr062i4300051ni0ui1q0.1

Date: Wed, 17 Aug 2011 07:09:54 GMT

Call-Info: <sip:10.2.1.33:5060>;method="NOTIFY;Event=telephone-event;Duration=500"

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

From: Anonymous<sip:anonymous@anonymous.invalid>;tag=c30442cd-dacd-4feb-93b3-3d6d192eb705-19666466

Allow-Events: presence, kpml

Supported: timer,resource-priority,replaces

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Min-SE: 1800

Remote-Party-ID: "NewName" <sip:*2221003@10.2.1.33>;party=calling;screen=yes;privacy=full

Content-Length: 0

User-Agent: Cisco-CUCM7.1

To: <sip:000112223335555@10.250.1.25>

Contact: <sip:1003@10.1.1.33:5060;transport=udp>

Expires: 180

Call-ID: e6da9280-e4b16942-3d-e300000a@10.2.1.33

CSeq: 101 INVITE

Session-Expires: 1800

Max-Forwards: 68

ISDN Message is sent out by GW

401169: Aug 17 2011 15:09:54.990 GMT: ISDN Se0/1/1:23 Q931: TX -> SETUP pd = 8  callref = 0x4D1E

        Bearer Capability i = 0x8090A2

                Standard = CCITT

                Transfer Capability = Speech 

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA98394

                Exclusive, Channel 20

        Progress Ind i = 0x8183 - Origination address is non-ISDN 

       Calling Party Number i = 0x0080, '*2221003'

                Plan:Unknown, Type:Unknown

        Called Party Number i = 0x80, '00602223335555'

                Plan:Unknown, Type:Unknown

Calling Party i=0x0080 doesn't contain any privacy field. After looking in the "debug ccsip all"

401125: Aug 17 2011 15:09:54.966 GMT: //-1/BE3C3784AA52/SIP/Info/sipSPISetInfoFromRpid: Received current remote name: NewName, current remote number: *2221003

<sip layer does see ocate3a as 0xA1>

401126: Aug 17 2011 15:09:54.966 GMT: //-1/BE3C3784AA52/SIP/Info/sipSPISetInfoFromRpid: Received ;screen=yes ;privacy=full -> Setting Octet3A 0xA1, extended_privacy 0x00

401127: Aug 17 2011 15:09:54.966 GMT: //-1/BE3C3784AA52/SIP/Info/sipSPIUaddCcbToUASReqTable: ****Adding to UAS Request table.

401128: Aug 17 2011 15:09:54.970 GMT: //-1/BE3C3784AA52/SIP/Info/sipSPIUaddCcbToTable: Added to table. ccb=0x45EEEC18 key=e6da9280-e4b16942-3d-e300000a@10.2.1.33+2223335555

401129: Aug 17 2011 15:09:54.970 GMT: //-1/BE3C3784AA52/SIP/Info/sipSPIMatchSrcIpGroup: Match not found on carrier id

401130: Aug 17 2011 15:09:54.970 GMT: //-1/BE3C3784AA52/SIP/Info/sipSPIMatchSrcIpGroup: Match not found on Incoming called number: +2223335555

401131: Aug 17 2011 15:09:54.970 GMT: //-1/BE3C3784AA52/SIP/Info/sipSPIMatchSrcIpGroup: Match not found on destination pattern: *2221003

But when SIP layer sends the calling info to CCAPI layer, it strips the octate3a value from 0xA1 to 0x00

401132: Aug 17 2011 15:09:54.970 GMT: //-1/BE3C3784AA52/SIP/Info/ccsipUpdateIncomingCallParams:

ccCallInfo: Calling name s1p3, number *2221003, Calling oct3 0x00, oct_3a 0x00, Called number +2223335555

401133: Aug 17 2011 15:09:54.970 GMT: //-1/BE3C3784AA52/SIP/Info/sipSPIGetCallConfig: Peer tag 1000 matched for incoming call

After comparing a working call on the GW with same configuration, we've found that * in the calling number is causing the SIP to misbehave.

Once the * in the calling number is removed from the SIP header, it worked ok.

Actions

Login or Register to take actions

This Blog

Posted April 19, 2011 at 3:30 AM
Stats:
Comments:20 Avg. Rating:4.4
Views:3460   
Shares:0

Blogs Leaderboard