Response group woes - Lync 2013, Exchange 2007 UM


I am trying to set up a very simple response group.  For inbound calls to our main number, we want them to first go to a response group of primary phone answerers (agent mode).  If nobody picks up prior to timeout (or the call is after hours), we want it to go to the auto attendant.  Pretty simple.

The problem is that when you call the response group number, the system simply hangs up.

We have Lync 2013 and Exchange 2007 UM.

On Exchange we have one dial plan and one auto-attendant.  On Lync we have a single response group, queue, and workflow linking them.  The group is informal with a 20 second timeout, attendant routing method and the agent is a distribution list of 6 people.  The queue also has a timeout of 20 seconds and is set to forward to voicemail afterward.  There are a lot of seeming redundancies between the workflow, the group and the queue and Im not sure I understand why.  The workflow is a simple hunt group where I have our main line telephone number associated with the primary answerers group and the single queue. The only other option Ive set is music on hold that sounds like ringback. Our gateway is an audiocodes M800. 

I have the same main phone number associated with our UM dial plan.  That was setup for us by a consultant.

I would like to better understand what kind of flow should be happening here.  We have the audiocodes simply pushing everything through to Lync.  I assume Lync first normalizes the number and then routes it.  I assume it looks for matching response workflows before it tries to find auto attendants?   Should I post an OCSlogger trace?

June 22nd, 2013 4:11am

First thing to try: In Lync control panel - disable refer support on the trunk. take a look at https://support.net.com/display/SSIPDOC/Disable+Refer+Support+(required+for+Transfer) for steps.

Free Windows Admin Tool Kit Click here and download it now
June 22nd, 2013 6:00pm

Thanks, it looks like our refer support is already set to none.  Any other ideas?
June 22nd, 2013 8:50pm

I'd recommend posting the OCSlogger trace.
Free Windows Admin Tool Kit Click here and download it now
June 23rd, 2013 1:38am

If you dial the configured E.164 number of your RSG Group, the call will emmediatly disconnect?

Lync will search for the normalized number, if this is a RSG Group, the call will accept directly from this RSG Group and the RSG Group search for a free Agent.

All numbers from the audicodes GW should be manipulate on the AC gw to the E.164 Format.

What happen if you call the RSG Group directly from Lync?

June 23rd, 2013 10:48am

Interesting, if I dial the RSG from a lync client, I get the "it is not necessary to dial a 1 ..." message from the PSTN.  Like lync is normalizing the number and then routing it outbound because it doesn't recognize it associated with anything inside.  There is no user linked to this number, just the response group workflow. 

When dialed from outside, it hangs up immediately.  The first hint of a problem in the trace is this parsing warning:

TL_INFO(TF_COMPONENT) [3]1D3C.3618::06/24/2013-19:46:43.152.000b4d33 (SIPStack,CISIPRequest::SetForked:3370.idx(1537))[1595322880]( 0000000009DD03C0 ) BranchNumber=0]
TL_WARN(TF_COMPONENT) [3]1D3C.208C::06/24/2013-19:46:43.153.000b52d5 (SIPStack,ParseURIEntry:2268.idx(347))Exit - Failed to parse the uri : sip:+14699169800.
TL_ERROR(TF_COMPONENT) [3]1D3C.208C::06/24/2013-19:46:43.153.000b52d6 (SIPStack,CISIPProxy::CreateUriFromString:1531.idx(1342))( 00000000003BC050 ) Exit - not a valid SIP address. Returned 0xC3E93F21(SIPPROXY_E_INVALID_URI)
TL_INFO(TF_COMPONENT) [1]1D3C.3618::06/24/2013-19:46:43.156.000b5de5 (SIPStack,CISIPRequest::SetForked:3370.idx(1537))[1595322880]( 0000000009DD47E0 ) BranchNumber=0]
TL_INFO(TF_COMPONENT) [3]1D3C.3618::06/24/2013-19:46:43.162.000b70dc (SIPStack,CISIPRequest::SetForked:3370.idx(1537))[1595322880]( 0000000009DD69F0 ) BranchNumber=0]
TL_INFO(TF_DIAG) [0]1D3C.3618::06/24/2013-19:46:43.175.000b74f5 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1207.idx(778))[1595322880] $$begin_record
Severity: information
Text: Routed a locally generated response
SIP-Start-Line: SIP/2.0 100 Trying
SIP-Call-ID: e9ce3426-e079-43e4-b4b8-b36bf9891c6e
SIP-CSeq: 102196 INVITE
Peer: lyncfront.yadallas.org:56867
$$end_record

Free Windows Admin Tool Kit Click here and download it now
June 24th, 2013 11:24pm

I'm confused by the initial thread.  Are you attempting to create a Response Group (one found in LSCP), or are you attempting to create a UM auto attendant?  These are two different items.

If Response Group, you can also attempt to dial the SIP URI from the the lync client to see if you can get a proper pick up.  Also, you can attempt to create a quick custom "Welcome Message"  to see if the Lync client is even hitting the RGS.

June 25th, 2013 12:15am

First I want to create a response group that rings a group of users in parallel.  If nobody in the group responds before timeout, then I want it to forward to a UM auto attendant, or at least a shared voice mailbox.  But right now I just want to complete the first step - get the response group working so that inbound calls go to the group.

If I try dialing the sip address of the group/workflow in the lync client, it initiates a conference call will all the members. 

It's like lync is not aware that the activated hunt group workflow is claiming that telephone number?  I'm not sure what to try next.

Free Windows Admin Tool Kit Click here and download it now
June 25th, 2013 11:53pm

Karim,

OK. Makes sense.  Let's start over and create a new RGS, get that to work, then move forward with the UM auto attendant.

Basic steps for RGS creation

1. Create a Group, change your routing method to parallel, and assign agents to that group.

2. Create a Queue, select the group from #1.  You can set the Queue timeout at that time.

3.  Create a RGS Workflow. Assign a unique SIP URI and Line URI to the RGS.  For example:

sip:rgs1@contoso.com

tel:+14255551212

On the last step, assign a queue that you created in #2. Click Save.

(At this time, you can also check to see if Event Viewer throws any warnings/errors based on the Response Group creation)

Now, from the Lync client, see if you can call both the telephone number (+14255551212) or the SIP URI (rgs1@contoso.com) from the Lync client.  This should ring the parallel users.

June 26th, 2013 12:36am

OK, I created a whole new RGS.  Created it per your instructions which are pretty much the way I did it last time.  The only difference is that I did not use a distribution group for the agents - I just assigned some individually.  This allowed me to put in a unique SIP URI.

So calling the SIP URI from the lync client worked!  I was able to hear the configured greeting.

But calling the telephone number (a different previously unassigned number) from the lync client failed in the same way - it routed to an outside PSTN line.  Calling the number from the outside again yielded an immediate disconnect.

Free Windows Admin Tool Kit Click here and download it now
June 26th, 2013 6:24am

Hi Karim,

Great!  Glad to hear you are making progress!

Let's go over our Line URI again.  You have something like: tel:+14255551212 for your RGS.

We need to match that Line URI when you dial that number.  There are many ways that  I can dial that telephone number and still get it to connect:

  • 4255551212
  • 14255551212
  • +14255551212

Of the numbers above, only the last one will work because it will exactly match the Line URI of the RGS.  If you dial the other two telephones, you will need to have a Lync Dial Plan associated with the user that is logged into the Lync Client you are doing the testing.  We need to make the first two entries look like the last entry automatically.

Let me point you to this blog, which explains how to create a Lync Dial Plan: http://www.lynclog.com/2012/02/lync-2010-dial-plan-mystery.html

June 26th, 2013 5:53pm

It was a noob mistake.  The dial plan was normalizing the number with an extension and it wouldn't match without that extension included in the line uri.  It's working great now.  Thanks to all posters who helped me along.
Free Windows Admin Tool Kit Click here and download it now
June 26th, 2013 9:15pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics