thr3ads.net - asterisk users - [asterisk-users] Asterisk <-> Lync / Call Center Transfer / Refer [Mar 2011]

If this information is useful, please help other people find it:
Share via:

Louis Carreiro

2011-Mar-04 14:07 UTC

[asterisk-users] Asterisk <-> Lync / Call Center Transfer / Refer

Hey all,

Alright. So we decided to not go with Avaya for our next PBX and we are now full
on into an Asterisk/Lync 2010 implementation. Asterisk/FreePBX is our SIP
gateway and call center and Lync is our internal UC and IP-PBX server. I've
already got Asterisk tied with our Nortel/Merridian Option 11 with QSig and all
is beautiful (except for the Opt11 not receiving names from * but that's
another topic). So, my problem now is with the call center.

This setup may be a bit convoluted at first but it'll make sense I hope.
I've created the queues in Asterisk via FreePBX. I then created a ring group
for each Lync extension so we get the "Confirm Calls" option and dodge
the voice mail problem. The agents the login via their Lync phone with the Ring
Group extension as their Agent ID. It kind of looks like this:

Queue 2001
	Agent 4001
	Agent 4002
	Agent 4003

Ring Group 4001 -> Lync Extention 5001
Ring Group 4002 -> Lync Extention 5002
Ring Group 4003 -> Lync Extention 5003

This all works beautifuly! The problem I have is on transfers. If Lync extension
5001 trasnfers to Lync extension 5010, Asterisk is unaware of the transfer and
shows that 5001 is still active with the call. We're using OrderlyStats to
monitor the queue so I watch the "Talking" counter just keep counting
instead of being aware the transfer took place. Now to me, that says to me that
the transfer took place within Lync so Asterisk is unaware of the transfer. So
my next step was to enable Refer support in Lync so Lync sends the refer message
back to Asterisk to transfer the call so Asterisk is fully aware of what's
going on. It seems like the refer message is trying to work and Lync is sending
it and Asterisk is receiving it but the "Refer-To" is changing between
the two so I'm at a loss.

(Logs are below signature)
Lync says it's sending the following message with a "Refer-to:
<sip:user2 at domainname.com>"

Asterisk is seeing the following and the refer-to changed, it's now
"REFER-TO:
<sip:Lyncserver.internal.domain:5067;transport=Tls;ms-opaque=3bb3da5834ad2787?REPLACES=aa6f8871-4151-4149-ad5a-29ab941bf4d0%3Bfrom-tag%3D9227b8a39d%3Bto-tag%3D8be38bb187>".

At first it seems like Lync is sending a true SIP URI so I need to get Asterisk
to know how to handle that SIP URI and then secondly, it seems like Asterisk
doesn't even receive the same REFER-TO message that Lync sent. Is this
because Asterisk doesn't know how to handle the SIP URI?

So I guess I'm left with wondering if fixing the REFER message stuff is
going to fix my problem even? The end goal is for Asterisk to be aware that a
call was transferred to another extension in Lync.



Thanks in advance everyone!
Louis


================================= Begin Lync SIP message
===========================================TL_INFO(TF_PROTOCOL)
[0]0B10.1E88::03/04/2011-13:21:17.501.0004fcd9
(SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record
Trace-Correlation-Id: 215606761
Instance-Id: 00011F02
Direction: outgoing
Peer: lyncserver.internal.domain:5070
Message-Type: request
Start-Line: REFER
sip:lyncserver.internal.domain:5070;grid=ed392a6bc0344a30b0841cd69be137ed
SIP/2.0
From: "" <sip:1173;phone-context=DefaultProfile at
domainname.com;user=phone>;epid=e9688aa93e;tag=8be38bb187
To: <sip:500;phone-context=DefaultProfile at
domainname.com;user=phone>;epid=B3E26C1E76;tag=9227b8a39d
CSeq: 2 REFER
Call-ID: aa6f8871-4151-4149-ad5a-29ab941bf4d0
Via: SIP/2.0/TLS
20.20.20.20:54166;branch=z9hG4bKEB39D72C.F05E7E34CF9EF4FD;branched=FALSE
Max-Forwards: 69
Via: SIP/2.0/TLS 172.16.2.29:53851;ms-received-port=53851;ms-received-cid=400
User-Agent: CPE/4.0.7577.107 OCPhone/4.0.7577.107 (Microsoft Lync 2010 Phone
Edition)
Supported: ms-dialog-route-set-update
Refer-to: <sip:user2 at domainname.com>
Referred-By: <sip:user1 at
domainname.com>;ms-referee-uri="sip:500;phone-context=enterprise at
domainname.com;user=phone";ms-identity="MIIBxwYJKoZIhvcNAQcCoIIBuDCCAbQCAQExDzANBgkqhkiG9w0BAQUFADALBgkqhkiG9w0BBwExggGPMIIBiwIBATBkMFYxFDASBgoJkiaJk/IsZAEZFgRSb290MRcwFQYKCZImiZPyLGQBGRYHTmV0d29yazElMCMGA1UEAxMcUGluY2ggQSBQZW5ueSBSb290IEF1dGhvcml0eQIKH1RMewAAAAAABjANBgkqhkiG9w0BAQUFADANBgkqhkiG9w0BAQEFAASCAQDCqFfl86RgR0gyLlbf6kEtUbFIWu2zCaFlqOoBWH/1ftxR80WwlsM142hImIGJhugOnXGIpCPMwC5OsPlD5Zk5+J371SSiz0dLhTjC1EzQzTMiIf9xbAd+ohi+e46TfXrJSN+esDNAafFKau0sj4hqPuuMh4EsabcNPrZwmroF5FX7zzEmRiavIKdGjyFgtwrwTIVkWjOnKdJdZN7T9jUj7Eb5HJGvOuG29LeJajTbogLugzsRA85RGQ7s+HMhU8F/RTJwQEvDhM4HQNeRFqUENi4jkYFUjuQaL3A2+Zqoml6LeZQNKU/afq8L9vck9+5qL1tc7c3+BtT+RxwlE92C:Fri,
04 Mar 2011 13:21:17
GMT";ms-identity-info="sip:Lyncserver.internal.domain:5061;transport=tls";ms-identity-alg=rsa-sha1
Content-Length: 0
P-Asserted-Identity: <sip:user1 at domainname.com>
Privacy: id
Message-Body: -
$$end_record
================================= End Lync SIP message
===========================================

================================= Begin Asterisk Debug
===========================================[Mar  4 08:21:05] DEBUG[18506]
chan_sip.c:  Header  0 [ 53]: REFER sip:500 at 10.10.10.10:5067;transport=TLS
SIP/2.0
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  1 [ 78]: FROM: <sip:1173
at lyncserver.internal.domain:5067>;epid=431D53633D;tag=42b6d8c72b
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  2 [ 46]: TO: <sip:500 at
10.10.10.10:5067>;tag=as0d823373
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  3 [ 13]: CSEQ: 2 REFER
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  4 [ 59]: CALL-ID:
4ad0626f79c7c8de66b668b13d624129 at 10.10.10.10:5067
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  5 [ 16]: MAX-FORWARDS: 70
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  6 [ 59]: VIA: SIP/2.0/TLS
20.20.20.20:5067;branch=z9hG4bK4614ad68
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  7 [ 86]: CONTACT:
<sip:Lyncserver.internal.domain:5067;transport=Tls;ms-opaque=3bb3da5834ad2787>
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  8 [ 17]: CONTENT-LENGTH: 0
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  9 [179]: REFER-TO:
<sip:Lyncserver.internal.domain:5067;transport=Tls;ms-opaque=3bb3da5834ad2787?REPLACES=aa6f8871-4151-4149-ad5a-29ab941bf4d0%3Bfrom-tag%3D9227b8a39d%3Bto-tag%3D8be38bb187>
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header 10 [ 40]: USER-AGENT:
RTCC/4.0.0.0 MediationServer
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header 11 [  0]:
[Mar  4 08:21:05] VERBOSE[18506] chan_sip.c:
<--- SIP read from TLS:20.20.20.20:5067 --->
REFER sip:500 at 10.10.10.10:5067;transport=TLS SIP/2.0
FROM: <sip:1173 at
lyncserver.internal.domain:5067>;epid=431D53633D;tag=42b6d8c72b
TO: <sip:500 at 10.10.10.10:5067>;tag=as0d823373
CSEQ: 2 REFER
CALL-ID: 4ad0626f79c7c8de66b668b13d624129 at 10.10.10.10:5067
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 20.20.20.20:5067;branch=z9hG4bK4614ad68
CONTACT:
<sip:Lyncserver.internal.domain:5067;transport=Tls;ms-opaque=3bb3da5834ad2787>
CONTENT-LENGTH: 0
REFER-TO:
<sip:Lyncserver.internal.domain:5067;transport=Tls;ms-opaque=3bb3da5834ad2787?REPLACES=aa6f8871-4151-4149-ad5a-29ab941bf4d0%3Bfrom-tag%3D9227b8a39d%3Bto-tag%3D8be38bb187>
USER-AGENT: RTCC/4.0.0.0 MediationServer

<------------->
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  0 [ 53]: REFER sip:500 at
10.10.10.10:5067;transport=TLS SIP/2.0
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  1 [ 78]: FROM: <sip:1173
at lyncserver.internal.domain:5067>;epid=431D53633D;tag=42b6d8c72b
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  2 [ 46]: TO: <sip:500 at
10.10.10.10:5067>;tag=as0d823373
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  3 [ 13]: CSEQ: 2 REFER
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  4 [ 59]: CALL-ID:
4ad0626f79c7c8de66b668b13d624129 at 10.10.10.10:5067
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  5 [ 16]: MAX-FORWARDS: 70
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  6 [ 59]: VIA: SIP/2.0/TLS
20.20.20.20:5067;branch=z9hG4bK4614ad68
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  7 [ 86]: CONTACT:
<sip:Lyncserver.internal.domain:5067;transport=Tls;ms-opaque=3bb3da5834ad2787>
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  8 [ 17]: CONTENT-LENGTH: 0
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header  9 [179]: REFER-TO:
<sip:Lyncserver.internal.domain:5067;transport=Tls;ms-opaque=3bb3da5834ad2787?REPLACES=aa6f8871-4151-4149-ad5a-29ab941bf4d0%3Bfrom-tag%3D9227b8a39d%3Bto-tag%3D8be38bb187>
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c:  Header 10 [ 40]: USER-AGENT:
RTCC/4.0.0.0 MediationServer
[Mar  4 08:21:05] VERBOSE[18506] chan_sip.c: --- (11 headers 0 lines) ---
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c: = Looking for  Call ID:
4ad0626f79c7c8de66b668b13d624129 at 10.10.10.10:5067 (Checking From) --From tag
42b6d8c72b --To-tag as0d823373
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c: **** Received REFER (9) - Command in
SIP REFER
[Mar  4 08:21:05] VERBOSE[18506] chan_sip.c: Call
4ad0626f79c7c8de66b668b13d624129 at 10.10.10.10:5067 got a SIP call transfer
from caller: (REFER)!
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c: Attended transfer: Will use
Replace-Call-ID : aa6f8871-4151-4149-ad5a-29ab941bf4d0 F-tag: 9227b8a39d T-tag:
8be38bb187
[Mar  4 08:21:05] VERBOSE[18506] chan_sip.c: SIP transfer to extension
Lyncserver.internal.domain:5067 at from-internal-xfer by (null)
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c: SIP attended transfer: Transferer
channel SIP/Lync-00000003, transferee channel DAHDI/i1/500-2
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c: Got SIP transfer, applying to bridged
peer 'DAHDI/i1/500-2'
[Mar  4 08:21:05] DEBUG[18502] manager.c: Examining event:
Event: VarSet
Privilege: dialplan,all
Channel: DAHDI/i1/500-2
Variable: SIPREFERRINGCONTEXT
Value: from-internal
Uniqueid: 1299244801.4


[Mar  4 08:21:05] DEBUG[18502] manager.c: Examining event:
Event: VarSet
Privilege: dialplan,all
Channel: DAHDI/i1/500-2
Variable: SIPREFERREDBYHDR
Value:
Uniqueid: 1299244801.4


[Mar  4 08:21:05] DEBUG[18497] manager.c: Examining event:
Event: VarSet
Privilege: dialplan,all
Channel: DAHDI/i1/500-2
Variable: SIPREFERRINGCONTEXT
Value: from-internal
Uniqueid: 1299244801.4


[Mar  4 08:21:05] DEBUG[18497] manager.c: Examining event:
Event: VarSet
Privilege: dialplan,all
Channel: DAHDI/i1/500-2
Variable: SIPREFERREDBYHDR
Value:
Uniqueid: 1299244801.4


[Mar  4 08:21:05] VERBOSE[18506] chan_sip.c:
<--- Transmitting (no NAT) to 20.20.20.20:5067 --->
SIP/2.0 202 Accepted
Via: SIP/2.0/TLS 20.20.20.20:5067;branch=z9hG4bK4614ad68;received=20.20.20.20
From: <sip:1173 at
lyncserver.internal.domain:5067>;epid=431D53633D;tag=42b6d8c72b
To: <sip:500 at 10.10.10.10:5067>;tag=as0d823373
Call-ID: 4ad0626f79c7c8de66b668b13d624129 at 10.10.10.10:5067
CSeq: 2 REFER
Server: FPBX-2.8.1(1.8.3)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH
Supported: replaces, timer
Contact: <sip:500 at 10.10.10.10:5067;transport=TLS>
Content-Length: 0


<------------>
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c: Trying to put 'SIP/2.0 202'
onto TLS socket destined for 20.20.20.20:5067
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c: Looking for callid
aa6f8871-4151-4149-ad5a-29ab941bf4d0 (fromtag 9227b8a39d totag 8be38bb187)
[Mar  4 08:21:05] DEBUG[18506] chan_sip.c: Strict routing enforced for session
4ad0626f79c7c8de66b668b13d624129 at 10.10.10.10:5067
[Mar  4 08:21:05] VERBOSE[18506] chan_sip.c: set_destination: Parsing
<sip:Lyncserver.internal.domain:5067;transport=Tls> for address/port to
send to
[Mar  4 08:21:05] DEBUG[18506] netsock2.c: Splitting
'Lyncserver.internal.domain:5067' gives...
[Mar  4 08:21:05] DEBUG[18506] netsock2.c: ...host
'Lyncserver.internal.domain' and port '5067'.
[Mar  4 08:21:05] VERBOSE[18506] chan_sip.c: set_destination: set destination to
20.20.20.20:5067
[Mar  4 08:21:05] VERBOSE[18506] chan_sip.c: Reliably Transmitting (no NAT) to
20.20.20.20:5067:
NOTIFY sip:Lyncserver.internal.domain:5067;transport=Tls SIP/2.0
Via: SIP/2.0/TLS 10.10.10.10:5067;branch=z9hG4bK05f81334
Max-Forwards: 70
From: <sip:500 at 10.10.10.10:5067>;tag=as0d823373
To: <sip:1173 at
lyncserver.internal.domain:5067>;epid=431D53633D;tag=42b6d8c72b
Contact: <sip:500 at 10.10.10.10:5067;transport=TLS>
Call-ID: 4ad0626f79c7c8de66b668b13d624129 at 10.10.10.10:5067
CSeq: 103 NOTIFY
User-Agent: FPBX-2.8.1(1.8.3)
Event: refer;id=2
Subscription-state: terminated;reason=noresource
Content-Type: message/sipfrag;version=2.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH
Supported: replaces, timer
Content-Length: 49

SIP/2.0 481 Call leg/transaction does not exist

---

================================= End Asterisk Debug
============================================

Danny Nicholas

2011-Mar-04 14:29 UTC

head link

[asterisk-users] Asterisk <-> Lync / Call Center Transfer / Refer

-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Louis Carreiro
Sent: Friday, March 04, 2011 8:07 AM
To: asterisk-users at lists.digium.com
Subject: [asterisk-users] Asterisk <-> Lync / Call Center Transfer / Refer

Hey all,

Alright. So we decided to not go with Avaya for our next PBX and we are now
full on into an Asterisk/Lync 2010 implementation. Asterisk/FreePBX is our
SIP gateway and call center and Lync is our internal UC and IP-PBX server.
I've already got Asterisk tied with our Nortel/Merridian Option 11 with QSig
and all is beautiful (except for the Opt11 not receiving names from * but
that's another topic). So, my problem now is with the call center.

This setup may be a bit convoluted at first but it'll make sense I hope.
I've created the queues in Asterisk via FreePBX. I then created a ring group
for each Lync extension so we get the "Confirm Calls" option and dodge
the
voice mail problem. The agents the login via their Lync phone with the Ring
Group extension as their Agent ID. It kind of looks like this:

Queue 2001
	Agent 4001
	Agent 4002
	Agent 4003

Ring Group 4001 -> Lync Extention 5001
Ring Group 4002 -> Lync Extention 5002
Ring Group 4003 -> Lync Extention 5003

This all works beautifuly! The problem I have is on transfers. If Lync
extension 5001 trasnfers to Lync extension 5010, Asterisk is unaware of the
transfer and shows that 5001 is still active with the call. We're using
OrderlyStats to monitor the queue so I watch the "Talking" counter
just keep
counting instead of being aware the transfer took place. Now to me, that
says to me that the transfer took place within Lync so Asterisk is unaware
of the transfer. So my next step was to enable Refer support in Lync so Lync
sends the refer message back to Asterisk to transfer the call so Asterisk is
fully aware of what's going on. It seems like the refer message is trying to
work and Lync is sending it and Asterisk is receiving it but the
"Refer-To"
is changing between the two so I'm at a loss.

(Logs are below signature)
Lync says it's sending the following message with a "Refer-to:
<sip:user2 at domainname.com>"

Asterisk is seeing the following and the refer-to changed, it's now
"REFER-TO:
<sip:Lyncserver.internal.domain:5067;transport=Tls;ms-opaque=3bb3da5834ad278
7?REPLACES=aa6f8871-4151-4149-ad5a-29ab941bf4d0%3Bfrom-tag%3D9227b8a39d%3Bto
-tag%3D8be38bb187>".

At first it seems like Lync is sending a true SIP URI so I need to get
Asterisk to know how to handle that SIP URI and then secondly, it seems like
Asterisk doesn't even receive the same REFER-TO message that Lync sent. Is
this because Asterisk doesn't know how to handle the SIP URI? 

So I guess I'm left with wondering if fixing the REFER message stuff is
going to fix my problem even? The end goal is for Asterisk to be aware that
a call was transferred to another extension in Lync.

Thanks in advance everyone!
Louis

<snip>

First of all, I assume you are using 1.8.X.  Regardless, Queueing and
referring have some known issues.  If you look at chan_sip.c, you'll see
that REFER is considered "broken" at this time (I know this to be the
case
in 1.4.37 and at least 1 flavor of 1.8).  So my suggestion is that you
either devise some workaround for this or set up multiple queues so you can
feed calls to these "phantom-busy" folks. My "Expertise"
(such as it is) is
at the AGI level; I only fool with the portions of the actual tree code that
are patently obvious (usually tweaks to patches).

Louis Carreiro

2011-Mar-07 02:32 UTC

head link

[asterisk-users] Asterisk <-> Lync / Call Center Transfer / Refer

So does anyone have any other thoughts about this? I've done some searching
through the bug tracker for Asterisk but haven't seen anything related to
refer's failing. Does anyone know of a specific issue number for this? If
not, is this a valid bug to submit? Also, does anyone remember an Asterisk
version that this worked on?

Thanks all!


On Fri, Mar 4, 2011 at 1:35 PM, Louis Carreiro <carreirolt at gmail.com>
wrote:
> Ha! Thanks Vip!
>
> Sorry about not including my version numbers too. On my production box
I'm
> using 1.8.3 (that's the debug from the original email). On my demo box
I
> just build I'm using 1.8 SVN-trunk-r309404 and that's what
generated these
> logs. I'm not sure if this is a chan_sip.c problem or if this is a dial
> plan problem.
>
> So digging in a bit deeper, Asterisk is receving the real REFER message.
> The "REFER-TO:
>
<sip:Lyncserver.internal.domain:5067;transport=Tls;ms-opaque=3bb3da5834ad2
> 787?REPLACES=aa6f8871-4151-4149-ad5a-29ab941bf4d0%3Bfrom-tag%3D9227b8a39d%
> 3Bto-tag%3D8be38bb187>" is accurate and in chan_sip.c it knows how
to
> manipulate it. It does grab the "from-tag" and "to-tag"
and parses the
> data.  On one of the lines below you can see it says "Looking for 
Call
> ID: 655e28eb45e0db7639856ec92ca88909 at 10.10.10.10:5060 (Checking From)
> --From tag 15826bef52 --To-tag as41bacc0b". Then it moves on to
bridging
> the peers/channels together. It's not until later that I get the final
"
> SIP/2.0 481 Call leg/transaction does not exist" which doesn't
make sense
> to me. Also, the Lync client says "Call was not transferred because
> [Original Extension] cannot be reached and may be offline."
> <-------- SNIP --------->
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20110306/8dcdf1b3/attachment.htm>

Apparently Analagous Threads

Search for more apparently analagous threads

asterisk users - Mar 2011 - Asterisk <-> Lync / Call Center Transfer / Refer

[asterisk-users] Asterisk <-> Lync / Call Center Transfer / Refer

[asterisk-users] Asterisk <-> Lync / Call Center Transfer / Refer

[asterisk-users] Asterisk <-> Lync / Call Center Transfer / Refer

Apparently Analagous Threads