14-01-24

Nec support suggested that to me, and that didn't help (though was something that I was missing).
Apparently what the issue is is that my sip provider isn't supported by nec. They use p-preferred identity headers for the cpn, and want the from to be my account number with them. Carrier F does this behavior for me. However apparently whatever carrier carrier F is doesn't like you using cpn that you don't own, and so nec has blocks the held party cpn being used. I tried using carrier N and, and using sip trunk messages customize to suit my needs, which did allow me to make calls properly and send sip messages that look the same as carrier F, but for some reason it still didn't work and sent out the trunk configured cpn. (and nec support did tell me that carrier n or b should work, past the fact that they by default don't work for my sip provider).
So apparently my issue is a very very specifically me issue, and although nec support might help me figure it out, I might just be screwed unless I convince my sip provider to get on the approved list.

No, not a YOU issue a THEM issue. Every SIP carrier does nothing in a standard way. First they don't bother to get certified...big red flag there. SIP carriers are precisely WHY I prefer my SIP on a PRI so things are "standardized". Frankly if the carrier cannot do this it's an out I would think to start shopping for another carrier that can. Don't get me wrong, I have spent hours (billable) to interface with non-certified SIP carriers and it's made me appreciate the flexibility of the SV series a LOT after working on other systems. Esp when integrating multiple SIP carriers AND I can use digital phones....

Well on the front of the sip trunk provider, they were panasonics sip trunking partner in Canada, and so we were already married to them before we were forced to move to nec. Certainly if this issue, which is the issue we have can't be solved (which I'm sure that I will solve it), we may have to think about transitioning our nec clients and new nec installs to a new provider though. I did send my provider and email before suggesting they get nec approved before though, and never got a response, but I may poke back at that and ask again.

Apparently it was working just fine, even though NEC told me with carrier F it isn't supposed to work? I believe the reason for that has something to do with the default setting for carrier F having "register sub-mode" on, which only works for my provider when turned off.
However, apparently my issue was that it only transfers the CID of the originator of a call, so when I call my personal cell, then transferred to the call fwd'ing extension, it was only transferring station i was calling from rather than the held party (even though I hung up within a second and the transfer became blind).
However, when calling the fwd'ing extension directly from DID, or receiving a call from DID and transferring it to the fwd'ing extension, it worked.
NEC support did give me a work-around for if a call ever needs to forwards with an extensions own CPN, or to transfer the held party CPN even when it was not the originator.

Quote (NEC Support.)

If the station is set to CFA 21-17 will be sent as the transferring station is still off hook when the call hits the sip trunk.
Most people set a virtual to call forward no answer and set 21-19 for the virtual, then but it in it own timer class and shorten the N/A timer to say 4 or 5 seconds, giving you time to hang up.

You know, a shot in the dark, look at 15-03-14.

Question, so it does work on a blind transfer correct? Only doesn't work on a supervised transfer?

It works on calls that originate from my sip trunks, but not calls that originate from a terminal.
It's the same behavior as transferring a call to a multiline terminal, which is how I realized it. If a terminal receives a call from CO and transfers it another multiline terminal, it will show the caller ID as being the first terminal, but when the first terminal hangs up and the transfer becomes unscreened, it will switch to the caller ID of the held party. (As you would expect) However, if the first terminal phones the outside number, then transfers that call to a MLT, then the MLT will only show the caller ID of the first terminal, even after it has hung up and it has become a unscreened transfer to the held party.

Try 15-03-14.

Didn't make a difference

Did you do it for all extensions that it affects?