QSIG and transfer - calling side drops

Answered Question
Oct 4th, 2007

Hi all

I have a problem to transfer incoming calls from the PSTN to an IP Phone. Here it is:

1) I call from PSTN to my IP Phone:::: OK

2) On the IP Phone, I transfer the call to another IP phone. I wait until this third party answers the call then I hit "Transfer" again and the call is transferred :::: OK

The problem :

1) I call from PSTN to my IP Phone :::: OK

2) On the IP Phone, I transfer the call to another IP phone, but this time I just dial the destination number and press the "Transfer" while receiving the ringback. On my PSTN phone I hear the ringback but once the call is answered, the call drops .

It only happens with my ISDN QSIG link to the PSTN. If I try this calling to a line connected on a FXO, it works just fine.

Is there any addictional parameter to be configured on the gateway ??

Regards !

Rodrigo

I have this problem too.
0 votes
Correct Answer by rob.huffman about 9 years 1 month ago

Hi Rodrigo,

What you are seeing is the CCM default for Transfer with QSIG. By default CCM supports Consultive Transfer (your scenario number 1) and not Blind Transfer (your scenario number 2). Have a look;

Call Transfer - QSIG

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00803edb19.html#wp1139777

Cisco CallManager supports call transfer by join only.

When a user transfers a call to another user, the QSIG identification service changes the connected name and number that displays on the transferred party phone. Call identification restrictions can impact what displays on the phone.

The call transfer supplementary service interacts with the path replacement feature to optimize the trunk connections when a call transfers to a caller in another PINX. For more information about path replacement, see

Path Replacement

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00803edb19.html#wp1156114

Hope this helps!

Rob

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
rob.huffman Thu, 10/04/2007 - 11:53

Hi Rodrigo,

What you are seeing is the CCM default for Transfer with QSIG. By default CCM supports Consultive Transfer (your scenario number 1) and not Blind Transfer (your scenario number 2). Have a look;

Call Transfer - QSIG

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00803edb19.html#wp1139777

Cisco CallManager supports call transfer by join only.

When a user transfers a call to another user, the QSIG identification service changes the connected name and number that displays on the transferred party phone. Call identification restrictions can impact what displays on the phone.

The call transfer supplementary service interacts with the path replacement feature to optimize the trunk connections when a call transfers to a caller in another PINX. For more information about path replacement, see

Path Replacement

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00803edb19.html#wp1156114

Hope this helps!

Rob

rcarrijoesilva Thu, 10/04/2007 - 13:39

Hello Rob

Thanks for your great help !

Let me just ask you one more thing. According to the "Path replacement" document, I understand that the exact reason why CM does not support blind transfer is ...

(from the second document you sent )

"Path Replacement

...

Note: Cisco CallManager provides "requesting" and "cooperating" PINX messages only. If configured for QSIG, Cisco CallManager responds to third-party vendor PINX "inviting" messages, although Cisco CallManager will not originate "inviting" messages."

Is it right ?

Thanks in advance,

Rodrigo

rob.huffman Thu, 10/04/2007 - 13:46

Hi Rodrigo,

First off, you are most welcome. And you are right on the money here :)

Hope this helps!

Rob

Paolo Bevilacqua Thu, 10/04/2007 - 13:49

Wait a moment. connection to PSTN, in my experience, is never QSIG. Any type of appropriate ISDN switch, yes. But not QSIG.

So please configure the correct switch-type and try again.

rcarrijoesilva Fri, 10/05/2007 - 06:50

Hello Bevilacqua

Here in Brazil is pretty common to have QSIG signaling to the PSTN. This deployment is an example of this. The carrier established this protocol for us.

Thank you !

Rodrigo

Paolo Bevilacqua Fri, 10/05/2007 - 07:00

Ok. In any case, collect debug isdq 931 if you see strange behavior again. It will tell exactly what is being doing in protocol if the GW can decode the qsig.

Actions

This Discussion