Home › Forums › Unified Communications › MiVoice Business › Hot desk ACD agent/SIP Softphone
- This topic has 3 replies, 2 voices, and was last updated 10 months ago by
Brian Heinz.
-
AuthorPosts
-
May 5, 2020 at 3:53 pm #6192
Kurt Bobinger
ParticipantWe recently setup a large call center using Hot Desk ACD Agrnts using SIP softphones (PC Client). The agents are required to do a screened transfer to other coworkers. As you all know this is a trans/conf feature of the MiVB. I have configured all parameters per Product support, which includes below:
The consultation transfer does work on the Sip Softphone, however requires a few additional configuration steps as it is a Sip Conference.There are 3 locations we need to input the Conference FAC from the PBX, which will allow the Micollab Client to create a conference.
First is on the Network Element for the PBX in User’s and Services It should be called Sip Conference FAC
Second is in the Deployment Profile used to deploy these clients, it will be called Conference Access Code,
Third will be the PBX Node in Micollab Client Services for that PBX, it will also be called Sip Conference FAC.
Add the conference FAC from the PBX to these three locations, redeploy, and test again!And:
However I think I may have forgot to mention a step, on the PBX we also need to have a Multicall key assigned to the sip softphone, which should allow it to use two lines for the conference.Here is where, i believe the issue lies. In order to configure an outgoing MC key you must program it as a virtual key. When the Agent attempts to perform the supervised transfer. the call is placed on hold and the other party is attempted to call, then the call fails and the original caller remains on hold.
I configured a test SIP softphone, as a NON-ACD EXT with a multicall key of it’s own prime EXT and the trans.conf works perfectly.
I have done a wire shark capture of the failure and here is what I find
Frame 221187: 454 bytes on wire (3632 bits), 454 bytes captured (3632 bits)
Encapsulation type: Linux cooked-mode capture (25)
Arrival Time: May 5, 2020 15:29:31.295577000 Central Daylight Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1588710571.295577000 seconds
[Time delta from previous captured frame: 0.000090000 seconds]
[Time delta from previous displayed frame: 0.025836000 seconds]
[Time since reference or first frame: 14.209731000 seconds]
Frame Number: 221187
Frame Length: 454 bytes (3632 bits)
Capture Length: 454 bytes (3632 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: sll:ethertype:ip:udp:sip]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Linux cooked capture
Packet type: Unicast to us (0)
Link-layer address type: 1
Link-layer address length: 6
Source: VMware_8c:67:15 (00:50:56:8c:67:15)
Unused: 0000
Protocol: IPv4 (0x0800)
Internet Protocol Version 4, Src: 172.150.0.2, Dst: 172.150.0.11
0100 …. = Version: 4
…. 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x68 (DSCP: AF31, ECN: Not-ECT)
0110 10.. = Differentiated Services Codepoint: Assured Forwarding 31 (26)
…. ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 438
Identification: 0x3d34 (15668)
Flags: 0x0000
0… …. …. …. = Reserved bit: Not set
.0.. …. …. …. = Don’t fragment: Not set
..0. …. …. …. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xe261 [validation disabled]
[Header checksum status: Unverified]
Source: 172.150.0.2
Destination: 172.150.0.11
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
Source Port: 5060
Destination Port: 5060
Length: 418
Checksum: 0xa61e [unverified]
[Checksum Status: Unverified]
[Stream index: 5]
[Timestamps]
[Time since first frame: 14.209374000 seconds]
[Time since previous frame: 0.025836000 seconds]
Session Initiation Protocol (403)
Status-Line: SIP/2.0 403 Forbidden
Status-Code: 403
[Resent Packet: False]
[Request Frame: 220517]
[Response Time (ms): 41]
Message Header
Via: SIP/2.0/UDP 172.150.0.11:5060;branch=z9hG4bK-d8754z-96214857d495b313-1—d8754z-;rport
Transport: UDP
Sent-by Address: 172.150.0.11
Sent-by port: 5060
Branch: z9hG4bK-d8754z-96214857d495b313-1—d8754z-
RPort: rport
Warning: 399 172.150.0.2 “29H Access Barred”
From: “3287” <sip:3287@172.150.0.2:5060>;tag=1afdaaf6b6
SIP Display info: “3287”
SIP from address: sip:3287@172.150.0.2:5060
SIP from address User Part: 3287
SIP from address Host Part: 172.150.0.2
SIP from address Host Port: 5060
SIP from tag: 1afdaaf6b6
To: <sip:1972@172.150.0.2:5060>;tag=0_2168079600-345873495
SIP to address: sip:1972@172.150.0.2:5060
SIP to address User Part: 1972
SIP to address Host Part: 172.150.0.2
SIP to address Host Port: 5060
SIP to tag: 0_2168079600-345873495
Call-ID: 73f260380811ff63Y
[Generated Call-ID: 73f260380811ff63Y]
CSeq: 24950 INVITE
Sequence Number: 24950
Method: INVITE
Contact: <sip:172.150.0.2>
Contact URI: sip:172.150.0.2
Contact URI Host Part: 172.150.0.2
Server: Mitel-3300-ICP 14.0.3.19
Content-Length: 0
172.150.0.2 is the MiVB
172.150.0.11 is the internal interface of the MBG
EXT 3287 is the HD ACD agent SIP Softphone.Any and all replies are appreciated!
May 5, 2020 at 4:00 pm #6193Brian Heinz
ParticipantHow are you creating the second line key for the ACD Agent, since and ACD agent ID can only be a single line appearance? Usually I’ll create a 2nd line derived from the agent ID (4*001 for Agent ID 4001, for example).
May 5, 2020 at 4:05 pm #6194Kurt Bobinger
ParticipantYes, same way, for example ACD AGENT 4001, the MC key is a single line key of **4001
May 5, 2020 at 5:19 pm #6195Brian Heinz
ParticipantI seem to recall hearing/reading something somewhere that MiCollab client doesn’t like extensions that start with *, so maybe try a different number format?
-
AuthorPosts
- You must be logged in to reply to this topic.