QSIG and transfer - calling side drops

Answered Question
Oct 4th, 2007
User Badges:

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

Correct Answer by Rob Huffman about 9 years 7 months 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
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 IP Telephony, Unified Communications

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
User Badges:

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
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 IP Telephony, Unified Communications

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
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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
User Badges:

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
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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