Blindtransfer a call on a SCA (shared) line fails


Using SCA on a UCM6202 - phone is a GXP2170. SCA works just fine, account(s) and VMPK(s) set up properly, etc.

However, if I answer a call coming in on an SCA line, I am unable to transfer the call. Neither a transfer VMPK nor a manual transfer works - the call just immediately comes back to me as soon as I press transfer.

The REFER request is receiving a response code 400, state 5. To be clearer, the REFER gets a 202 accepted from the UCM which is then immediately followed by a sipfrag NOTIFY 100 trying and then a sipfrag NOTIFY 400 Bad request.

Any ideas? Transfer works properly on non-SCA lines on the same phone, using the same transfer VMPK.


I am just guessing here, but if sipfrag means fragmented packets, then SIP won’t work because it does not support fragmented packets. I have seen fragmented packets in the past where too many CODECs were specified between the phone and the UCM. My suggestion, FWIW, is to limit the number of Codecs to one or two.

Hope this helps.


Thanks - sipfrag is a type of sip packet - you will normally see them on notify’s. Different from fragmented sip packets.


I do not use SCA, but my understanding of SCA is that when used, some functionality is removed of which call transfer is one. The point of SCA is that a given line is shared between phones much as it was when key set systems were in use. In that era, the call would be placed on hold and then the destination party would be notified and pick up the call by pressing the correct flashing line button.

The shared function essentially makes the SCA extensions seem as one (the same) when a private number/line call is received. Calls are transferred by placing the call on hold and then picked up at the desired location/extension (depending on if the call was held privately or using the normal hold-button - public). Lines that are not shared are able to transfer normally.

SCA was introduced to accommodate those who wanted to monitor and handle calls on specific lines using keys on the extensions. In normal operation, the inbound and outbound call handling is transparent to the user as the system handles the calls based on the defined rules.


What lpneblett said. If you want to use SCA/SLA, then basically everything else the PBX does, is lost. I always steer customers away from this option. It doesn’t work as expected because of Asterisk, not because of Grandstream.


Do you know this to be a fact?

I’ve opened a ticket with support, and they have requested additional information and are looking into it - I would assume that if the above were true they would just say that.

And you would expect a similar statement in the UCM and phone documentation - and the Grandstream SCA implementation document(s). There is nothing in the documentation that says you will lose all other functions.

Asterisk itself is certainly limited in SCA function - it just doesn’t exist in Asterisk at all. There is no Asterisk based reason that transfer couldn’t work.


To answer your question simply, Yes, I know this to be a fact. What Grandstream calls SCA is actually SLA in Asterisk.
As for your other statements, I wish you well in getting Grandstream to re-write Asterisk SLA. The Grandstream SCA guide does not mention “Transfer” as something you can or cannot do, nor does it mention that you lose Voicemail, etc., but that’s exactly what happens.

If you wish to learn more, please look at the limitations of Asterisk SLA. To Quote one of the limitations from “Another limitation, most relevant to usage of shared extensions, is that transfers do not work. The main reason is that transfers generally involve putting a call on hold for a short time. Call hold is processed in a special way with SLA, in that the held call is not controlled by the phone that initiated the hold. This breaks transfer processing.”


Thanks for the info.

I was under the understanding that Grandstream implemented Broadsoft SCA function.

Broadsoft SCA is just old Asterisk SLA? I thought they were two totally different things.


While I did not look at the link, as I do not use the function, maybe it will help define how GS uses the function -


Thank you for that link - I did look at that a few days ago.

It just reinforces my thoughts that there is a functional difference between SLA and SCA. Grandstream’s implementation of SLA seems to be by the book old fashioned Asterisk SLA. They make a distinction between the two.


… and here is a screenshot from a slide in that presentation that specifically says that transfer works with SCA.



Interesting to say the least. My take for what its worth -

Despite the presentation, I do not believe the “transfer” function works when the phones involved are a member of the SCA group.

This leaves us with the following possibilities:
1, I am wrong (more often than I would like), and GS has a method of doing so that is not readily apparent to us.
2. I am correct and the presentation is incorrect.
3. We are both correct depending upon the context as you can transfer when using non-SCA line numbers.
4. There is a bug in the function in which case I am correct and the presentation is incorrect, but only momentarily until they fix and the tables turn.

The biggest difference I see (not withstanding the transfer function) is that the connectivity is expanded in the SCA to encompass more than just analog.

It will be interesting to see what support has to say. I still stick with my understanding that transfers do not work in this scenario. Others have noted the same and I like you, think that the GS SCA implementation is an offshoot of SLA,


Anything is possible, of course. But I find it hard to believe that Grandstream would make a point of making that specific distinction (features dont won’t on SLA & features do work on SCA) unless they knew it to be true.

Keep in mind, again as I understand it, that SLA is a function of Asterisk. SCA is not a function of Asterisk, but a function of external code “simulating” the functions.


Support tells me that, based on my open ticket, the dev team will begin working on a fix for this problem.


Well…if true, then you are one lucky person. Will be looking for it.


An update:

Grandstream has told me that “The transfer issue with SCA will be fixed in the future, but not at least in the upcoming quarter.”

Unfortunately, my current project can’t wait so I will be going another route. I do hope the problem does get fixed eventually. But, like others on this thread, I don’t think I’ll hold my breath.

I still do find it very odd that Granstream sales, within the past month or so, made a video specifically touting that features work with SCA when they actually don’t. No one bothered to test even a simple transfer before making that video?



Do you have any update on this? it is Sept.2020 and i still have the same issue with transfer from SCA extension



As far as I know nothing has changed.


SCA appears totally unusable for me, mostly because of limit of 10 private extensions in single SCA :frowning: