다음을 통해 공유

Call transfer on Cisco VoIP gateway

  • 아티클

First, the only call xfer type available for us (at least at this moment) is tromboning ("hair-pin"). It has quite obvious pros and cons: it works no matter what kind of telephony protocol you're using (interoperable as long as your gateway can perform outbound calls) but the gateway stays in the call for the duration of the transferred call when both call legs belong to PSTN (resulting into two channels allocated, which is quite expensive).

 

Do I need anything special configured for the call transfer?

Yes. By default the call xfer won’t work. You’ll have to configure a different application the inbound dial-peer for calls that are expected to use transfer later:

dial-peer voice 200 pots
application session
incoming called-number .
direct-inward-dial

  • “application session” tells the gateway to use and application that “knows” how to transfer a call. By default, the “DEFAULT” application is used.
  • “incoming called-number . ” allows this dial-peer to be used as inbound dial-peer for any DNIS.
  • “direct-inward-dial” allows you to avoid “assistance” from the gateway w.r.t. collecting additional information from the called like phone extension. Read “Understanding Direct-Inward-Dial (DID) on IOS Voice Digital (T1/E1) Interfaces”

if you want to understand DID more.

Now all calls coming from the PSTN through this dial-peer will be processed by the “session” application and will be able to perform call xfer later.

Note: It seems that Cisco has added new command that helps to avoid configuring this “application session” for each inbound dial-peer: “call application global session”. I didn't try it yet.

 

Call transfer still doesn’t work. Why?

Many reasons but I’d start from verifying whether the application for the original call is configured correctly. Turn on “deb voip ccapi inout” (it’s a very chatty debug command, be sure that you don’t run calls through this gateway while you’re playing with it). Look through the output. If you see this:

*May 19 04:24:53.602: //13141/BACA45859589/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 13141 with tag 100 to app "DEFAULT"

then you didn’t configure your gateway correctly. This call still goes through the dial-peer (in this case, it’s a dial-peer 100) that doesn’t have “application session” configured.

If you see application "session” there, then you’ll have to look at the time when the call transfer is initiated. Turn on “deb voip ccapi inout” and “deb ccsip messages” and see what happens when REFER arrives.

 

7-, 10-digit numbers and a prefix “9”…

Some time ago I ran into this issue with the outbound calls (and transfer as well). What appeared to be a misunderstanding between Cisco GW and PBX SL-100 (which our GW is connected to) with respect to the TON (TypeOfNumber) field for the Called Party Number, produced quite amazing ISDN Q.931 message exchange:

*Jun 6 01:04:04.735: ISDN Se3/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0421
Bearer Capability i = 0x8090A2
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0x2180, '4255554592'
Plan:ISDN, Type:National
Called Party Number i = 0xC1, '95557310'
Plan:ISDN, Type:Subscriber(local)
*Jun 6 01:04:04.831: ISDN Se3/0:23 Q931: RX <- STATUS pd = 8 callref = 0x8421
Cause i = 0x808B - Excessive digits received, call is proceeding
Call State i = 0x01
*Jun 6 01:04:04.835: ISDN Se3/0:23 Q931: TX -> STATUS pd = 8 callref = 0x0421
Cause i = 0x80E4 - Invalid information element contents
Call State i = 0x01
*Jun 6 01:04:04.839: ISDN Se3/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8421
Channel ID i = 0xA98397
Exclusive, Channel 23
*Jun 6 01:04:04.843: ISDN Se3/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x8421
Cause i = 0x809C - Invalid number format (incomplete number)
*Jun 6 01:04:04.843: ISDN Se3/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x0421
*Jun 6 01:04:04.879: ISDN Se3/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8421

So, in the Q.931 SETUP we provide 7-digit number with “9” prefix. The PBX didn’t really like the 8-digit number, complaining “Excessive digits received” in the Q.931 STATUS.

(Interestingly enough, Cisco GW didn’t like this STATUS message either, complaining back with “Invalid information element contents”. This status exchange is harmless – both sides just keep complaining :-).

I guess, PBX didn’t only complain about extra digits, it also cut them off. The DISCONNECT cause code says “incomplete number”.

There are two solutions to this:

  1. Move switch type configured both on the Cisco GW and PBX to DMS-100. (I actually didn’t try this, only heard that as a recommendation).
  2. Configure the Cisco GW to change TON to “Unknown”. Quite simple translation rule would help:
    (In the global config)
    translation-rule 1
    Rule 1 ^9 9 ANY unknown
    (In the outbound dial-peer)
    translate-outgoing called 1

Comments