IP Office and SIP connection to IVR doesn't work.

[wrenchmonkey]

I have been doing some testing with an IVR and have ran into an issue with Release 9.0. It appears when using SIP endpoints, Avaya is no longer allowing REFER and when using SIP trunks they are preventing a blind transfer. I've ran monitor and wireshark to verifying what I'm seeing. Has anyone seen this issue or have any suggestions? Below is the monitor trace of the REFER failing on the SIP endpoints followed by the message when the SIP trunk transfer fails. Just a few notes, I did edit the telephone number in the monitor trace and I have upgraded to the latest release (last night), but other than the version number that's displayed, the problem remains consistent. Another small detail is that in a monitor trace from version 8.1.43, when the IP Office responds, it actually includes the REFER option that is now missing. Any suggestions are greatly appreciated.

Montior output for SIP extensions

10:03:23 24681860mS SIP Rx: UDP 192.168.2.237:5060 -> 192.168.2.220:5060
REFER sip:700@192.168.2.220:5060;transport=udp SIP/2.0
From: <sip:750@192.168.2.220>;tag=31182f0-ed02a8c0-13c4-50022-e90b-7261b37b-e90b
To: "CPATE"<sip:700@192.168.2.220>;tag=3dc4da779f1d3a8c
Call-ID: 20aeee752f533c9a95c0aa7232decfb0
CSeq: 1 REFER
Via: SIP/2.0/UDP 192.168.2.237:5060;branch=z9hG4bK-e911-38e6d08-7793f006
Refer-To: <sip:701@192.168.2.220>
Referred-By: <sip:750@192.168.2.237>
Max-Forwards: 70
Supported: replaces
Contact: <sip:750@192.168.2.237>
Allow: INVITE, CANCEL, ACK, BYE, OPTIONS, INFO, REFER, NOTIFY
Allow-Events: refer
Content-Length: 0

10:03:23 24681862mS SIP Call Rx: phone
REFER sip:700@192.168.2.220:5060;transport=udp SIP/2.0
From: <sip:750@192.168.2.220>;tag=31182f0-ed02a8c0-13c4-50022-e90b-7261b37b-e90b
To: "CPA"<sip:700@192.168.2.220>;tag=3dc4da779f1d3a8c
Call-ID: 20aeee752f533c9a95c0aa7232decfb0
CSeq: 1 REFER
Via: SIP/2.0/UDP 192.168.2.237:5060;branch=z9hG4bK-e911-38e6d08-7793f006
Refer-To: <sip:701@192.168.2.220>
Referred-By: <sip:750@192.168.2.237>
Max-Forwards: 70
Supported: replaces
Contact: <sip:750@192.168.2.237>
[highlight #FCE94F]Allow: INVITE, CANCEL, ACK, BYE, OPTIONS, INFO, REFER, NOTIFY[/highlight]
Allow-Events: refer
Content-Length: 0

10:03:23 24681863mS SIP Call Tx: phone
SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/UDP 192.168.2.237:5060;branch=z9hG4bK-e911-38e6d08-7793f006
From: <sip:750@192.168.2.220>;tag=31182f0-ed02a8c0-13c4-50022-e90b-7261b37b-e90b
Call-ID: 20aeee752f533c9a95c0aa7232decfb0
CSeq: 1 REFER
[highlight #FCE94F] Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,NOTIFY,SUBSCRIBE,REGISTER,PUBLISH,UPDATE[/highlight]
Supported: timer,100rel
Server: IP Office 9.0.2.0 build 860
Reason: Q.850;cause=63;text="Service or option not available, unspecified"
To: "CPA" <sip:700@192.168.2.220>;tag=3dc4da779f1d3a8c
Content-Length: 0

10:03:23 24681864mS SIP Tx: UDP 192.168.2.220:5060 -> 192.168.2.237:5060
SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/UDP 192.168.2.237:5060;branch=z9hG4bK-e911-38e6d08-7793f006
From: <sip:750@192.168.2.220>;tag=31182f0-ed02a8c0-13c4-50022-e90b-7261b37b-e90b
Call-ID: 20aeee752f533c9a95c0aa7232decfb0
CSeq: 1 REFER
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,NOTIFY,SUBSCRIBE,REGISTER,PUBLISH,UPDATE
Supported: timer,100rel
Server: IP Office 9.0.2.0 build 860
Reason: Q.850;cause=63;text="Service or option not available, unspecified"
To: "CPA" <sip:700@192.168.2.220>;tag=3dc4da779f1d3a8c
Content-Length: 0


Montior output for SIP trunk

12:25:13 7895714mS SIP Rx: UDP 192.168.2.237:5060 -> 192.168.2.220:5060
REFER sip:701@192.168.2.220:5060;transport=udp SIP/2.0
From: "8888888888"<sip:8654751049@192.168.2.220>;tag=30989d0-ed02a8c0-13c4-50022-283d2-4901e0db-283d2
To: <sip:701@192.168.2.220>;tag=6c6c1ee3e4edeb7e
Call-ID: 30a0678-ed02a8c0-13c4-50022-283d2-78b19265-283d2
CSeq: 2 REFER
Via: SIP/2.0/UDP 192.168.2.237:5060;branch=z9hG4bK-283e1-9d32893-23708af7
Refer-To: <sip:702@192.168.2.220>
Referred-By: <sip:192.168.2.237:5060>
Max-Forwards: 70
Supported: replaces
Contact: <sip:4000@192.168.2.237:5060>
Allow: INVITE, CANCEL, ACK, BYE, OPTIONS, INFO, REFER, NOTIFY
Allow-Events: refer
Content-Length: 0

12:25:13 7895717mS SIP Call Rx: 17
REFER sip:701@192.168.2.220:5060;transport=udp SIP/2.0
From: "8888888888"<sip:8654751049@192.168.2.220>;tag=30989d0-ed02a8c0-13c4-50022-283d2-4901e0db-283d2
To: <sip:701@192.168.2.220>;tag=6c6c1ee3e4edeb7e
Call-ID: 30a0678-ed02a8c0-13c4-50022-283d2-78b19265-283d2
CSeq: 2 REFER
Via: SIP/2.0/UDP 192.168.2.237:5060;branch=z9hG4bK-283e1-9d32893-23708af7
Refer-To: <sip:702@192.168.2.220>
Referred-By: <sip:192.168.2.237:5060>
Max-Forwards: 70
Supported: replaces
Contact: <sip:4000@192.168.2.237:5060>
Allow: INVITE, CANCEL, ACK, BYE, OPTIONS, INFO, REFER, NOTIFY
Allow-Events: refer
Content-Length: 0

12:25:13 7895718mS [highlight #FCE94F]Sip: 17.1100.1 27 SIPTrunk Endpoint(f4a56310) Blind transfer is not allowed on trunks[/highlight]
12:25:13 7895718mS Sip: SIPTrunkEndpointDialogOwner::SetRemoteAddressForResponse from 192.168.2.237:5060 to 192.168.2.237:5060
12:25:13 7895719mS SIP Call Tx: 17
SIP/2.0 481 Dialog/Transaction Does Not Exist
Via: SIP/2.0/UDP 192.168.2.237:5060;branch=z9hG4bK-283e1-9d32893-23708af7
From: "8888888888" <sip:8654751049@192.168.2.220>;tag=30989d0-ed02a8c0-13c4-50022-283d2-4901e0db-283d2
Call-ID: 30a0678-ed02a8c0-13c4-50022-283d2-78b19265-283d2
CSeq: 2 REFER
Supported: timer
Server: IP Office 9.0.1.0 build 845
Reason: Q.850;cause=41;text="Temporary failure"
To: <sip:701@192.168.2.220>;tag=6c6c1ee3e4edeb7e
Content-Length: 0

12:25:13 7895719mS SIP Tx: UDP 192.168.2.220:5060 -> 192.168.2.237:5060
SIP/2.0 481 Dialog/Transaction Does Not Exist
Via: SIP/2.0/UDP 192.168.2.237:5060;branch=z9hG4bK-283e1-9d32893-23708af7
From: "8888888888" <sip:8888888888@192.168.2.220>;tag=30989d0-ed02a8c0-13c4-50022-283d2-4901e0db-283d2
Call-ID: 30a0678-ed02a8c0-13c4-50022-283d2-78b19265-283d2
CSeq: 2 REFER
Supported: timer
Server: IP Office 9.0.1.0 build 845
Reason: Q.850;cause=41;text="Temporary failure"
To: <sip:701@192.168.2.220>;tag=6c6c1ee3e4edeb7e
Content-Length: 0

 

[wrenchmonkey]

Clarification. The end result of both issues is that blind transfers (unsupervised) will not work. No transfer will work with the SIP endpoint, assisted transfers will work with the SIP trunks.

 

[amriddle01]

It happens, IPO is crap with SIP endpoints and transferring, always has been, more don't work than do

 

[hairlessupportmonkey]

Turn call waiting on the SIP Endpoints, and delete the CA keys.

ACSS - SME
General Geek

 

[wrenchmonkey]

amriddle, I agree (I so agree!), but I'm still stuck staring at a screen hoping to figure out a resolution.

HSM. No CA keys and call waiting is enabled.

I've tried every variation I can think of. I'm stumped why it appears Avaya has removed the REFER option on sip endpoints. It's one of those, it use to be there. Outside of putting an SBC between the two, can anyone think of any other possible resolutions? Any suggestions that would emulate something? With the SIP trunks, assisted transfer works...any thoughts on making the IP Office believe a blind transfer is an assisted transfer?

Thanks in advance for any suggestions, solutions or advice (On the advice piece, lets assume I have to make it work on the IP Office )

 

[amriddle01]

They haven't removed the option, it still works with a narrow range of endpoints, I can't personally see any difference in those that don't work and those that do, but I guess monitor only shows what it's programmed to show not everything that actually happens

 

[wrenchmonkey]

Amriddle, that's interesting. Do you have any customers that are running 9.0 and using the REFER for SIP endpoints? It's not just monitor, wireshark is what I was using to validate my information. If you happen to have a trace from any customer showing that I would REALLY appreciate you sharing it. I've currently left voicemails and sent emails to our Avaya RFE (but he's in training for the next few weeks, so I'm in wait mode). If I can validate it behaving in a different manner with a Dev-Connect partner versus a non Dev-Connect partner it would certainly be a very interesting conversation. Even if the accepted replies vary between products, it would be an interesting conversation. Aside from that, any thoughts on making the SIP trunk work with a blind transfer? I've toyed with the idea of passing it through voicemail pro as a relay, but I haven't tested that yet. Any suggestions, even out of the box ideas I could investigate? As always, I apprecate your (and everyone else's) assistance.

Free drinks for a day for anyone that can help me with a creative solution that works (and that's a sure sign that I've already had a few myself!)!

 

[intrigrant]

From the Avaya docs:
Blind Transfer with REFER:
If REFER is enabled, IP Office will send a REFER message to the SIP trunk when an inbound call is transferred to the PSTN. If the transfer is completed before the transfer destination answers (blind transfer), then IP Office sends an unexpected re-INVITE to the SIP trunk after the call has been transferred resulting in a “481
Unknown Dialog” response from the SIP ytunk.
However, the call is properly transferred so there is no user impact to this behavior.

In your case the provider send the message "Sip: 17.1100.1 27 SIPTrunk Endpoint(f4a56310) Blind transfer is not allowed on trunks" so it is the other end ( not IP Office) which cannot handle the blind transfer.
NOTE: currently there is a issue with IP Office R8.1 & R9 were the message "SIP/2.0 481 Dialog/Transaction Does Not Exist" can cause a reboot of IP Office.
JIRA IPOFFICE-49877

 

[hairlessupportmonkey]

what are the endpoints?

ACSS - SME
General Geek

 

[wrenchmonkey]

Intrigrant, I was reading it the other way, but I see what you're saying. I'm going to do some more wire shark traces and dig deeper into that. Thanks!

HSM. The endpoints are just IVR ports. On the trunk scenario I can't change anything, on the SIP extension scenario I just have my extensions to manipulate. As far as specifics on the IVR port types, I don't really have much information.

 

[alandala]

wrenchmonkey were you able to find any response to this issue?
I am seeing the very same behavior with an IVR implementation I am currently testing. The blind transfer using REFER worked on earlier versions but on v9.0.1.0 build 845 is not working. I tested both SIP trunk with blind transfer and SIP station.
Thank you in advance for any hints that could lead to fixing the REFER issue.
Ala

 

[wrenchmonkey]

I'm currently working with Avaya Tier 4 and the development team on this. Hopefully there will be a patch soon. I've requested the patch based on the latest build. I'll update you on any progress. Utilizing SIP trunks as opposed to endpoints supports some, but not all features (blind transfer still fails).

 

[alandala]

We tested the exact scenario with a Bria:
[ul]
[li]register as a station (same user),[/li]
[li]made an inbound call to Bria Client,[/li]
[li]Bria initiates a transfer,[/li]
[li]IPO handles the transfer correctly.[/li]
[/ul]

When IVR registers as the same user\station, make inbound call to IVR, IVR transfers the call, IPO responds with 405 Method not Allowed.
I compared line by line all headers and all content of the calls.
Bria has a different call flow, it clones the inbound call:
[ul]
[li]Bria answers the inbound call,[/li]
[li]makes a call to IPO with the same call-id,[/li]
[li]IPO answers the cloned call[/li]
[li]the REFER method is sent to IPO, IPO handles the transfer properly.[/li]
[/ul]
I am not sure why it clones the call by sending another INVITE to IPO as i haven't seen that scenario in any other implementations before.
SDP was negotiated correctly when Bria answered the inbound call and IPO state of the call was identical right before transfer, on both cases.
Also when calling to Bria, IPO sends 100 Trying then 180 Ringing versus when calling to IVR there is only 180 Ringing but i don't think this would make any difference. I have traces for both cases but they might be too lengthy to copy here.

Did you consider adding a proxy or SBC to change the outcome?
Thanks for answering!
Ala

 

[nascom1]

I'm having a similar issue with IPO 9.0.0 and an IVR but using SIP endpoints. Using the IVR, REFER is not offered as an acceptable method but when testing the endpoint with Linphone, REFER is allowed (and works).

Did you get a solution to your SIP Trunk issue wrenchmonkey ?

 

[wrenchmonkey]

It's still sitting with Avaya's R&D.