SIP Refer disconnected 2

[mjm23]

Hello! I have a newly built system that integrates Asterisk with Avaya. Call flow goes like this: Customer calls the hotline in the Asterisk platform then gets routed to Avaya Experience portal after the caller selects the appropriate option. Caller hears the IVR from AAEP and after selecting the option to route to an Agent, the call gets disconnected. Looks like SM is initiating a BYE message but I cant understand why as there is no error in the trace.

Asterisk is connected to SM, then CM, MPP is connected to SM. Below are the logs I captured from the MPP and SIP traces as well:

@2021-03-13 05:17:43,259||FINER|Tele|9822|FileName=sip/SIPTCP.cpp,LineNumber=493|SIPTCP::SendSIPMsg: buffer=0xe9831068, len=728|mpp-01.abc.local####
@2021-03-13 05:17:43,259||FINEST|Tele|9822|FileName=sip/UAInterface.cpp,LineNumber=481|cUAInterface::SendToNetwork: rval=728, length=728|mpp-01.abc.local####
@2021-03-13 05:17:43,259||FINEST|Tele|9822|FileName=sip/UAInterface.cpp,LineNumber=120|cUADialog::ClearCall: envoked with reason 15000, headers= 0|mpp-01.abc.local####
@2021-03-13 05:17:43,259||FINEST|Tele|9822|FileName=sip/UAInterface.cpp,LineNumber=120|cUADialog::ClearCall: starting clearing timer|mpp-01.abc.local####
@2021-03-13 05:17:43,259||FINE|Tele|9822|FileName=sip/UAInterface.cpp,LineNumber=221|cUAInterface::TimerFactory: Function(0x108049c) Data(0xe98495a8) duration(5000)|mpp-01.abc.local####
@2021-03-13 05:17:43,259||FINEST|Tele|9822|FileName=sip/UAInterface.cpp,LineNumber=120|cUADialog::ClearCall: called in state 12|mpp-01.abc.local####
@2021-03-13 05:17:43,259||FINEST|Tele|9822|FileName=sip/UAInterface.cpp,LineNumber=120|cUADialog::ClearCall: call-id=62a5f124714cdac61f0015984cb68f19@10.173.117.11, from-tag=c6b2a176c82eb199f00a5a3944, to-tag=as31ee6512|mpp-01.abc.local####
@2021-03-13 05:17:43,259||FINEST|Tele|9822|FileName=sip/UAInterface.cpp,LineNumber=120|cUADialog::ClearCall: BUILDING SIP BYE in state = 12|mpp-01.abc.local####
@2021-03-13 05:17:43,259||FINEST|Tele|9822|FileName=sip/UAInterface.cpp,LineNumber=311|UASocketAddress = 10.173.117.11|mpp-01.abc.local####
@2021-03-13 05:17:43,259||FINEST|Tele|9822|FileName=sip/UAInterface.cpp,LineNumber=399|cUAInterface::GetPeerName: socket 7005 found 10.173.117.11:5060|mpp-01.abc.local####
@2021-03-13 05:17:43,259||FINE|SIP|9822|FileName=sip/UAInterface.cpp,LineNumber=479|SND sock=78:7005 src=10.173.173.57:32319 dst=10.173.117.11:5060 <^BYE sip:006593861127@192.168.192.167:5060;gsid=1be19650-846e-11eb-b0bb-005056868a2a;asm=1 SIP/2.0

From: sip:5610022@10.173.117.11:5062;tag=c6b2a176c82eb199f00a5a3944
To: "006593861127" <sip:006593861127@10.173.117.11>;tag=as31ee6512
Call-ID: 62a5f124714cdac61f0015984cb68f19@10.173.117.11
CSeq: 2 BYE
Max-Forwards: 70
Route: <sip:sm1@10.173.117.11;transport=tcp;lr;av-asset-uid=ab939b0>
Route: <sip:127.0.0.2:15060;transport=tcp;ibmsid=local.1587013557443_20267060_20267069;lr;ibmdrr>
Route: <sip:127.0.0.2:15060;transport=udp;ibmsid=local.1587013557443_20267060_20267069;lr;ibmdrr>
Route: <sip:sm1@10.173.117.11:5062;transport=udp;lr;av-asset-uid=ab939b0>
Via: SIP/2.0/TCP 10.173.173.57;branch=z9hG4bKf6be9276c82eb1b6f00a5a3944
User-Agent: Avaya-VoicePortal/7.2.0.0.1117
Av-Global-Session-ID: 1be19650-846e-11eb-b0bb-005056868a2a
Content-Length: 0

Thanks for your help!

 

[kyle555]

The refer is being sent from AAEP to SM and to Asterisk. Its up to Asterisk to know what to do with it. Does it create a new call to be setup to the number in the Refer-to header?

What's a SIP trace show? I can promise you the Refer is making its way back to Asterisk.
If the REFER doesn't get a 202 ACCEPTED within a certain amount of time, the referring party will probably drop it.

You can try tweaking the transfer settings in AAEP. There's a few options in there, maybe that's easier than fighting with Asstricks.

 

[mjm23]

Attached is the SIP trace. I can see that Asterisk is responding with 202 Accepted response after the REFER.

https://files.engineering.com/getfi...17e-40bb-af99-179200b15862&file=SIP_REFER.JPG

 

[kyle555]

Look at the NOTIFYs

If you send me a call and I want you to blind xfer to PSTN, I send a REFER and you 202 accept to me. Now you send an invite to the PSTN and the PSTN might give a 180 ringing. You'll put that in the NOTIFY to me.

So, the NOTIFYs are telling you what's happening with the new call leg.

 

[mjm23]

I see 2 NOTIFYs in the new call leg. First one shows that Subscription-state is active and has 180 Ringing then just a split second after, another NOTIFY message comes in with Subscription-state terminated;reason=noresource. Both NOTIFYs came from the remote end which is Asterisk. Does this mean they dont have resources to continue with the REFER call?

 

[kyle555]

It means there's a call trace somewhere on Asterisk where it was handling your transfer and whatever it was doing with it got progress to 180 Ringing and then termination for some reason.

And it's not a SIP message the terminated no resource. Almost q931-like.

Here's why Avaya SBC has a refer handling feature.

Without Refer Handling:
-Call comes from PSTN to SBC
-SBC goes to SM and then AAEP
-AAEP transfers to a CM hunt group extension via REFER - extension 2222
-AAEP sends REFER to SM, then to SBC
-What does the SBC do with it?
-SBC sends the REFER to the PSTN carrier.
-PSTN says "WTF is #2222?"
-Call drops

Now, if there was a DID that mapped to extension 2222, you could have referred to 555-555-2222 and the PSTN would have blind transferred the call from AAEP back to your SBC to CM.

With Refer Handling:
Without Refer Handling:
-Call comes from PSTN to SBC
-SBC goes to SM and then AAEP
-AAEP transfers to a CM hunt group extension via REFER - extension 2222
-AAEP sends REFER to SM, then to SBC
-What does the SBC do with it?
-SBC creates a new call, inward to the same SM, to 2222
-SM sends to CM
-CM answers
-SBC completes the REFER from AAEP and AAEP says BYE.

You can probably tweak AAEP to not do blind refer transfers and have AAEP setup the 2nd call, bridge them, and drop out after they're connected, but it's a waste of ports if that matters to you.

That, or have Asterisk know what to do with the refer-to extension AAEP is sending.
That, or maybe Asterisk has a similar feature to what I've described. It's in the SBC Overview Guide if you want pretty pictures.

 

[mjm23]

Thanks kyle555. I totally agree with the SBC thing. The REFER works seamlessly when calls go through our SBC. Integration with Asterisk is by the way is through WAN. I am interested with your first suggestion: "You can probably tweak AAEP to not do blind refer transfers and have AAEP setup the 2nd call, bridge them, and drop out after they're connected, but it's a waste of ports if that matters to you." How do I achieve this? We've got spare AAEP ports so I think we can deal with the extra ports utilization. I did change some configs in the SIP section of the VOIP Connections. Instead of "REFER", I chose "INVITE with REPLACES" but the issue remain. Is this the one you're referring to or is it something else?

 

[kyle555]

That's the one, yeah.

Do you have the AAEP test application running?

 

[mjm23]

Yes I have it running. I'm just wondering, even after I already selected "INVITE with REPLACES" instead of "REFER", I still see the MPP sends a REFER message back to the SM. Is this working as designed or should I see an INVITE instead?

 

[kyle555]

Maybe its different for blind/consultative. I was suggesting the test app so you could try both types of xfer with both types of settings to see what's what

 

[mjm23]

Got this resolved on Asterisk side. Turns out that the Asterisk version is not capable of handling REFER messages. They made changes on their end and voila! Thanks for all your help kyle555!