Transfers

Over the last week – in between New Years Eve and a sipsorcery.com crash – I’ve been doing some work on supporting SIP transfers aka REFER requests. I’ve been able to get transfers working between the Bria Softphone and Zoiper Communicator. I didn’t want to disrupt sipsorcery.com so soon after the recent outage so at the moment the update that supports transfers is only available on the sipwizard.net server. Transfers are supported on sipsorcery.com.

Only attended transfers are handled by the sipwizard server as it does not make sense for blind transfers to be processed by a signalling only SIP application server instead blind transfer requests are passed through to the user agent at the other end of the call to process as they see fit.
Both attended and blind transfers are supported. With blind transfers a dial string option can be used to determine whether to process the transfer on the sipsorcery server or to pass it through to the user agent on the other end of the call. Attended transfers are always processed on the server since the user agent on the other end of the call will not know anything about the dialogue being replaced.

There are some additional dial string options that can control the processing of REFER requests. One thing to be cautious of is blind transfers where a malicious called party could send a blind transfer to a premium rate number or such. There are different ways that could be handled: in theory user agents should ask for confirmation before accepting a blind transfer, apart from that I may change have changed the software so that blind transfers are disabled by default and only passed through if explicitly configured on a call by call basis. Of course premium number ranges could also be blocked within the dialplan but there would always be the possibility that a destination had been missed or some other attack was possible.

The new dial string parameter is tr (which stands for transfer). The values it can have are:

  • n for no transfers allowed in which case all REFER requests will be rejected. This is the default value and does not need to be set.
  • p for pass through in which case all blind transfer requests will be forwarded to the user agent on the other end of the dialogue. Attended transfers will still be processed on the sipwizard server.
  • c for place call. Attended transfers will be processed by server, blind transfers will intiate a new call on server and then do an attended transfer. For a blind transfer the Refer-To URI will be sent to a dialplan with a name of transfer, if it doesn’t exist the transfer will fail.

If anyone is using SIP transfers I’d be interested to know whether it works for them through sipwizard.net. I’m currently away from my Polycom and Cisco IP Phones and plan on doing some more testing with them next week.

# To explicitly block all transfer attempts. This is the default operation if there is no tr dial string option.
sys.Dial("1234@provider[tr=n]")

# To process blind transfers in a transfer dialplan.
sys.Dial("1234@provider[tr=c]")

# To pass through transfer requests to the user agent.
sys.Dial("aaron@local[tr=p]")
  1. Mike Telis’s avatar

    Tried to get it to work with SPA-3102 — no luck. A typical picture (trying to transfer *600 – Voxalot echo test to 303 — speaking clock:

    DialPlan 09:44:08:503: Commencing Dial with: *600@Voxalot[tr=b].
    DialPlan 09:44:08:503: Attempting to locate a provider for call leg: sip:*600@Voxalot.
    DialPlan 09:44:08:503: ForkCall commencing call leg to sip:*600@us.voxalot.com.
    DialPlan 09:44:08:503: Switching to sip:*600@us.voxalot.com:5060 via udp:10.211.86.52:5060.
    DialPlan 09:44:08:503: SDP on UAC call had public IP not mangled, RTP socket 83.237.58.236:16460.
    DialPlan 09:44:08:769: Response 407 Proxy Authentication Required for sip:*600@us.voxalot.com.
    DialPlan 09:44:09:019: Information response 100 Trying for sip:*600@us.voxalot.com.
    DialPlan 09:44:09:019: Information response 100 trying — your call is important to us for sip:*600@us.voxalot.com.
    DialPlan 09:44:09:019: Response 200 OK for sip:*600@us.voxalot.com.
    DialPlan 09:44:09:019: SDP on UAC response had public IP not mangled, RTP socket 202.60.88.238:13816.
    DialPlan 09:44:09:019: Cancelling all call legs for ForkCall app.
    DialPlan 09:44:09:035: Answering client call with a response status of 200.
    DialPlan 09:44:09:300: Dial command was successfully answered in 0.80s.
    DialPlan 09:44:09:378: Dial plan execution completed with normal clearing.
    DialPlan 09:44:14:456: Matching dialogue found for INVITE to sip:174.129.234.254:5060 from udp:10.211.86.52:5060.
    DialPlan 09:44:14:519: Forwarding re-INVITE from udp:10.211.86.52:5060 to sip:600@202.60.88.238:5061, first hop udp:10.211.86.52:5060.
    DialPlan 09:44:15:066: Forwarding in dialogue from udp:10.211.86.52:5060 INVITE info response 100 trying — your call is important to us to 10.211.86.52:5060.
    DialPlan 09:44:15:300: Forwarding in dialogue from udp:10.211.86.52:5060 INVITE final response 200 OK to 10.211.86.52:5060.
    DialPlan 09:44:26:410: Matching dialogue found for REFER to sip:174.129.234.254:5060 from udp:10.211.86.52:5060.
    DialPlan 09:44:26:410: REFER received on dialogue L(sip:*600@sipwizard.net)-R(sip:mtelis@sipwizard.net), transfer mode is Allowed.
    DialPlan 09:44:26:410: REFER received, blind transfer, Refer-To=, Referred-By=Mike Telis .
    DialPlan 09:44:26:472: Forwarding in dialogue REFER from udp:10.211.86.52:5060 to sip:600@202.60.88.238:5061, first hop udp:10.211.86.52:5060.
    DialPlan 09:44:27:003: Forwarding in dialogue from udp:10.211.86.52:5060 REFER final response 603 Declined to 10.211.86.52:5060.
    DialPlan 09:44:27:285: Matching dialogue found for BYE to sip:174.129.234.254:5060 from udp:10.211.86.52:5060.

    I also tried blind transfer to PSTN line, the situation was even worse because it seems that Sipwizard was trying to connect to 127.0.0.1:5080 (my PSTN SIP proxy), I have no idea whether it replaced local IP with real IP but whatever was the case, Sipwizard apparently didn’t have the credentials it needed to connect. So, I think it’s not going to work unless I disable VoIP user authentication which I’m not willing to do.

    There also is a persistent problem with sys.DBRead / sys.DBWrite at Sipwizard:

    DialPlan 09:54:42:613: Exception DBRead. Unable to connect to any of the specified MySQL hosts.

    It prevents me from migration to this server, could you please take a look?

    Sincerely,

    Mike

    Reply

    1. sipsorcery’s avatar

      Thanks for the feedback. One thing on your trace is that the Refer-To header should never be blank so I’ve made a mistake there somewhere.

      DialPlan 09:44:26:410: REFER received, blind transfer, Refer-To=, Referred-By=Mike Telis .

      Also the message below is not from the sipwizard server and I suspect the end you were trying to transfer to has them disabled.

      DialPlan 09:44:27:003: Forwarding in dialogue from udp:10.211.86.52:5060 REFER final response 603 Declined to 10.211.86.52:5060.

      You’ll find a lot of providers don’t support or block transfers so it’s best to start testing between two of your own devices.

      I’m back home after Christmas now and have all my IP phones to test with again. There are a few issues already so I’ve got some more work to do and it’s probably worth waiting until that’s complete before trying anymore transfers.

      In regards to the user database on sipwizard the issue is that I didn’t ever set it up. I will do so shortly. Don’t migrate to sipwizard as it’s a development system only and won’t be replacing sipsorcery. Instead sipsorcery will incorporate the sipwizard features I’ve been testing out, namely SQL Azure integration. That will be happening this month.

      Aaron

      Reply

    2. Mike Telis’s avatar

      Aaron, thanks for the new feature, I’d love to be able to transfer calls. The most valuable for me function is transferring from VoIP to PSTN using SPA-3102’s blind transfer. I didn’t mean I wouldn’t use VoIP->VoIP transfer but these are not my first necessity.

      I believe that the 603 response came from my Linksys SPA-3102. I know this device can do transfers when connected to a local IP PBX but it would be ingenious to get it working with Sipsorcery 😉

      It was a poor choice of word on my side. I didn’t want to migrate to Sipwizard but I did port my dialplan and other settings there. It was when I discovered that sys.DBxxx functions didn’t work and I reported that in the forum.

      sys.DBxxx is not something I can’t live without but if you could fix this issue I’d highly appreciate it.

      Sincerely,

      Mike

      Reply

Reply

Your email address will not be published. Required fields are marked *