I finally found the time to investigate this further. The JIRA in question hasn't been reintroduced, but the issue wasn't completely fixed AFAIC. It's simply a matter of how text strings are constructed, though, so should be an easy fix if ACD hasn't been abandoned altogether.
>From what I can tell, the intention is to add queue information to the display name portion of the To: header, so the agent can determine the appropriate response. That is completely reasonable, but the implementation isn't... 1. If the queue description is non-empty, the From: display name is constructed as follows: Queue description + Original display name + (queue extension) [BAD] If the queue description is empty, the queue _name_ is being instead, which is what I would expect in both cases [GOOD] The queue description can be quite long, and doesn't make much sense to include in the display name string... (Also, a very long display name will confuse / break certain phones..) 2. ITSPs in my part of the world tend not to send a display name (blank), particularly if the call originates from PSTN. In these cases, any phone I've tested (Polycom, Bria, Linksys etc) displays the user portion of the SIP URI instead. With the current display name transformation, no identification of the calling party is presented to the agents. If the original display name is blank, the resulting display name should be constructed with the user from the SIP URI. 3. Finally, the To: header is also constructed using the queue description, which doesn't make sense. Med vennlig hilsen / Best regards Anders Mydland 2011/6/6 Douglas Hubler <[email protected]>: > On Mon, Jun 6, 2011 at 9:21 AM, Anders Mydland <[email protected]> wrote: >> It appears that issue XX-5648 - "Caller ID for agent call is not >> correct in ACD" - has been reintroduced in 4.4's plain old ACD. >> >> In any case, I get the ACD queue name/extension as the caller ID for >> any queued call to my agent phone >> >> Can anyone confirm that this is not expected behavior? > > Are you using SIP trunk? If so, there were fixes w/PAI header and > >From address in/out of sipXbridge (SIP Trunking component). Can you > capture the packets in/out of sipXbridge to see if they are not what > you desire? > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
