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

Louis Carreiro carreirolt at gmail.com
Fri Mar 4 12:35:44 CST 2011


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=3bb3da5834ad2787?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."

<------------->
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c:  Header  0 [ 53]: REFER sip:1820 at 10.10.10.10:5060;transport=TCP SIP/2.0
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c:  Header  1 [ 78]: FROM: <sip:1173 at lyncserver.internal.name:5068>;epid=E5790B0758;tag=15826bef52
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c:  Header  2 [ 41]: TO: <sip:1820 at 10.10.10.10>;tag=as41bacc0b
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c:  Header  3 [ 13]: CSEQ: 2 REFER
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c:  Header  4 [ 58]: CALL-ID: 655e28eb45e0db7639856ec92ca88909 at 10.10.10.10:5060
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c:  Header  5 [ 16]: MAX-FORWARDS: 70
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c:  Header  6 [ 59]: VIA: SIP/2.0/TCP 20.20.20.20:5068;branch=z9hG4bK70e8a145
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c:  Header  7 [107]: CONTACT: <sip:lyncserver.internal.name:5068;transport=Tcp;maddr=20.20.20.20;ms-opaque=09aa43d8a2a895b9>
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c:  Header  8 [ 17]: CONTENT-LENGTH: 0
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c:  Header  9 [200]: REFER-TO: <sip:lyncserver.internal.name:5068;transport=Tcp;maddr=20.20.20.20;ms-opaque=09aa43d8a2a895b9?REPLACES=a9b5f241-5e9d-4439-b347-2cac9384a627%3Bfrom-tag%3Daa19f11d4f%3Bto-tag%3D7a9abe27a5>
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c:  Header 10 [ 40]: USER-AGENT: RTCC/4.0.0.0 MediationServer
[Mar  4 12:54:53] VERBOSE[11296] chan_sip.c: --- (11 headers 0 lines) ---
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c: = Looking for  Call ID: 655e28eb45e0db7639856ec92ca88909 at 10.10.10.10:5060 (Checking From) --From tag 15826bef52 --To-tag as41bacc0b
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c: **** Received REFER (9) - Command in SIP REFER
[Mar  4 12:54:53] VERBOSE[11296] chan_sip.c: Call 655e28eb45e0db7639856ec92ca88909 at 10.10.10.10:5060 got a SIP call transfer from caller: (REFER)!
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c: Attended transfer: Will use Replace-Call-ID : a9b5f241-5e9d-4439-b347-2cac9384a627 F-tag: aa19f11d4f T-tag: 7a9abe27a5
[Mar  4 12:54:53] VERBOSE[11296] chan_sip.c: SIP transfer to extension lyncserver.internal.name:5068 at from-internal-xfer by (null)
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c: SIP attended transfer: Transferer channel SIP/Lync-00000003, transferee channel SIP/1820-00000002
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c: Got SIP transfer, applying to bridged peer 'SIP/1820-00000002'
[Mar  4 12:54:53] VERBOSE[11296] chan_sip.c:
<--- Transmitting (no NAT) to 20.20.20.20:5068 --->
SIP/2.0 202 Accepted
Via: SIP/2.0/TCP 20.20.20.20:5068;branch=z9hG4bK70e8a145;received=20.20.20.20
From: <sip:1173 at lyncserver.internal.name:5068>;epid=E5790B0758;tag=15826bef52
To: <sip:1820 at 10.10.10.10>;tag=as41bacc0b
Call-ID: 655e28eb45e0db7639856ec92ca88909 at 10.10.10.10:5060
CSeq: 2 REFER
Server: FPBX-2.8.1(1.8)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:1820 at 10.10.10.10:5060;transport=TCP>
Content-Length: 0


<------------>
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c: Trying to put 'SIP/2.0 202' onto TCP socket destined for 20.20.20.20:5068
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c: Looking for callid a9b5f241-5e9d-4439-b347-2cac9384a627 (fromtag aa19f11d4f totag 7a9abe27a5)
[Mar  4 12:54:53] DEBUG[11296] chan_sip.c: Strict routing enforced for session 655e28eb45e0db7639856ec92ca88909 at 10.10.10.10:5060
[Mar  4 12:54:53] VERBOSE[11296] chan_sip.c: set_destination: Parsing <sip:lyncserver.internal.name:5068;transport=Tcp;maddr=20.20.20.20> for address/port to send to
[Mar  4 12:54:53] DEBUG[11296] netsock2.c: Splitting 'lyncserver.internal.name:5068' gives...
[Mar  4 12:54:53] DEBUG[11296] netsock2.c: ...host 'lyncserver.internal.name' and port '5068'.
[Mar  4 12:54:53] DEBUG[11293] manager.c: Examining event:
Event: VarSet
Privilege: dialplan,all
Channel: SIP/1820-00000002
Variable: SIPREFERRINGCONTEXT
Value: from-internal
Uniqueid: 1299261284.2


[Mar  4 12:54:53] DEBUG[11293] manager.c: Examining event:
Event: VarSet
Privilege: dialplan,all
Channel: SIP/1820-00000002
Variable: SIPREFERREDBYHDR
Value:
Uniqueid: 1299261284.2


[Mar  4 12:54:53] DEBUG[11296] netsock2.c: Splitting '20.20.20.20' gives...
[Mar  4 12:54:53] DEBUG[11296] netsock2.c: ...host '20.20.20.20' and port '(null)'.
[Mar  4 12:54:53] VERBOSE[11296] chan_sip.c: set_destination: set destination to 20.20.20.20:5068
[Mar  4 12:54:53] VERBOSE[11296] chan_sip.c: Reliably Transmitting (no NAT) to 20.20.20.20:5068:
NOTIFY sip:lyncserver.internal.name:5068;transport=Tcp;maddr=20.20.20.20 SIP/2.0
Via: SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bK3f177f10
Max-Forwards: 70
From: <sip:1820 at 10.10.10.10>;tag=as41bacc0b
To: <sip:1173 at lyncserver.internal.name:5068>;epid=E5790B0758;tag=15826bef52
Contact: <sip:1820 at 10.10.10.10:5060;transport=TCP>
Call-ID: 655e28eb45e0db7639856ec92ca88909 at 10.10.10.10:5060
CSeq: 103 NOTIFY
User-Agent: FPBX-2.8.1(1.8)
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


-----Original Message-----
From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of vip killa
Sent: Friday, March 04, 2011 11:35 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Asterisk <-> Lync / Call Center Transfer / Refer

I feel your pain


On Fri, Mar 4, 2011 at 9:29 AM, Danny Nicholas <danny at debsinc.com> wrote:


	-----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 <mailto:sip%3Auser2 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).
	


	--
	_____________________________________________________________________
	-- Bandwidth and Colocation Provided by http://www.api-digital.com --
	New to Asterisk? Join us for a live introductory webinar every Thurs:
	              http://www.asterisk.org/hello
	
	asterisk-users mailing list
	To UNSUBSCRIBE or update options visit:
	  http://lists.digium.com/mailman/listinfo/asterisk-users
	






More information about the asterisk-users mailing list