5 thoughts on - OT – How Does The Blind Transfer Function Work On Snom-870?

• Am 05.03.2015 um 01:09 schrieb James B. Byrne:

  Hi,

  I hope I understood your question correctly. AFAIK, the transfer button sends a SIP message. Entering “##” on the handset is recognized via DTMF by asterisk.

• I hope that I understood what I was asking for. Sometimes I do not.

  Yes, that is what I wanted to know. Does the implementation of the transfer button feature on the Snomp-870 use exactly the same technique as the ## feature code entered through the dial pad and produce exactly the same SIP message that Asterisk produces when it gets the ## DTMF?

  The reason is that I wish to be able to detect a call transfer performed via either method (## or ) and process the result of both in the same fashion. If the button and DTMF transfers are not performed using the same switching techniques in Asterisk then I need to discover what those differences are. If both are totally equivalent from a SIP message signalling point of view then the issue is far easier to handle.

  I searched, in vain, in the Snom-870 docs for specifics on this and either could not find or did not recognize anything that applied. Do you know where I can locate these sorts of details. My knowledge of SIP/RTP/VOIP etc. is cursory but, given an adequate reference, I can usually sort things out.

• Am 05.03.2015 um 15:09 schrieb James B. Byrne:

  Hi again,

  I’m glad to hear that I provided a somehow useful answer.

  Unfortunatelly, I don’t know these details. If you wasn’t lucky consulting the snom docs, maybe the snom support can be helpful with information about the exact implementation details.

  You also could use “sip debug” on asterisk to check what’s going on when pressing the transfer button vs. what’s happening when using “##” via DTMF.

  Are you forced to get the transfer information from the SIP signaling, or can you use AMI events for example? I think this would be possible if asterisk is configured to stay in the media path, so re-inviting is handled over asterisk itself and therefore detectable with AMI events.

  Regards, Ruben

• I am working with a FreePBX12/Asterisk11 setup. Asterisk stays on the path (B2B) and there are no peer-to-peer re-invites.

  What I am trying to do is to get our Snom870s to use a distinctive ring tone when external calls are transferred internally. I have an extension context override that detects the origin of calls and assigns a distinctive ring to each based on “${CallerIDNum}”.

  But when a call is transferred then the tone does not change since the CallerIDNum does not. An external original call always rings as if it were coming from the outside (which it is but transferred calls have a different handling procedure than unanswered calls). I need some way to distinguish when the call has already been answered at least once without changing the CallerID.

  I am not worried about attended transfers since then the internal ring tone is what should be used and that is what happens now. I just need to deal with blind transfers.

  What I have now is:

  1. Outside call => ring1
  2. Internal call => ring2
  3. Transferred call => ring1 || ring2 (depending on 1 or 2)

  What I want is:

  1. Outside call => ring1
  2. Internal call => ring2
  3. Transferred call => ring3 (regardless of 1 or 2)

  If everything went though ## then that would be simple enough. The trick is that most (all) users employ the transfer button and the touch screen to forward calls using blind transfer. But whatever method they use to transfer I want the transfer ring tone to be the same, albeit different from the one used for a new incoming call.

  If the transfer is done using a sip message then that should be doable as well. I just have to discover what the message is. If someone already knows and would care to share the information then that would be helpful. Otherwise wireshark and debug will eventually reveal it.

  I may not know what I am doing. But, at least I know that I do not know what I am doing.

• Take a look at two variables you can set on your SIP peer.

  TRANSFER_CONTEXT and FORWARD_CONTEXT

  You should be able to use this syntax in your sip.conf

  setvar=_TRANSFER_CONTEXT=kiniston-xfr

  You can then create the logic you need in your dialplan to change the ring using something like

  exten => _XXX,1,SIPAddHeader(Alert-Info: Ring1)
  exten => _XXX,1,Goto(INTERNAL-EXTENSIONS,${EXTEN},1)

  Or you could modify your extension macro and have a test there to see if the call has been blind transferred.with

  ExecIf($[${LEN(${BLINDTRANSFER})} > 0 ]?SIPAddHeader(Alert-Info: Ring1))