Attached Data not propagated from Avaya to SIP

[vma]

I call from a mobile phone (673976***) a DDI number which is mapped to Avaya VDN 3601.
3601 is scripted to be controlled by Genesys.
DN 3601 is created in Genesys as RP in Avaya switch, and has a strategy attached to it, called 'URS-mapping'.  In this strategy I attach kvp 'Call_Type' = 'Customer'.
Strategy 'URS-mapping' is sending the call to a next RP 3800, which is RP created in SIP switch.
The transfer from Avaya switch to SIP switch is done through ISCC, using External RP created on SIP switch, 3810.

On 3800, there is a new strategy called 'URS-nexthop', where based on the 'Call_Type' kvp the call is sent to another RP on SIP switch and then to an agent.
The transfer from SIP switch to Avaya switch is controlled by ISCC, using External RP created on Avaya switch 3610.

The call is ok, voice ok, pop-up screen in GAD ok, but attached data from the first strategy 'Call_Type' = 'Customer', is not available in GAD.
In fact, I see different ConnIDs for the call landing to Avaya and the call transferred from Avaya switch to SIP switch.

ISCC is using default values:
Target Type = Target ISCC
Route Type = route

Is there any options I have ignored?
Anyone can help pls?
Thank you!

Logs for Avaya, SIP server and URS can be found here: [URL=http://fileshost.com/download.php?id=ABB844471]here[/URL]

[René]

Hi vma,

I see in the logs that ISCC transaction is created and ExtRP 3810 on SIP Server side is reserved. However, the call from Avaya is sent directly to RP 3800 on SIP Server so it is direct transfer instead of ISCC transfer. And that's the reason why UserData are not passed to SIP Server and later to an agent.

Please check value of 'use_extrouter' option key of URS application (should be 'false') as I see that ISCC transfer is controlled by URS instead of T-Server. It is possible configuration but not a standard one... Check your routing strategy as well.

R.

[vma]

tried this but still not working
this is the last remaining issues from my avaya-genesys integration and is the most important one cause after forwarding the call to SIP I have no ideea on what Avaya RP the call has landed.

Rene u are saying that what we have here is not a standard configuration. What is a standard configuration?

[René]

Hi Mihai,

[quote]Rene u are saying that what we have here is not a standard configuration. What is a standard configuration?[/quote]
As I wrote URS option 'use_extrouter' is by default set to 'false' while it seems to be enabled (true) in your environment. It means that ISCC is handled by URS and not by T-Server. Such configuration is possible but it isn't standard one.

[quote]this is the last remaining issues from my avaya-genesys integration and is the most important one cause after forwarding the call to SIP I have no ideea on what Avaya RP the call has landed.[/quote]
Your issue is not caused by call landing on Avaya RP but by call being sent directly to RP on SIP Server side instead to External RP.

R.

[vma]

Thanks Rene but it seems I´m lost in all this
As you are saying, my problem is sending the call directly to RP3800. I,m doing this in a strategy by Selection object where I choose as target the 3800 RP. I thought that URS knows to send this call trough 3810 XRP by default.
How should I do it then? How should I send the call from 3601 (which is on Avaya) to 3800 on SIP?

[René]

Hi Mihai,

[quote]As you are saying, my problem is sending the call directly to RP3800. I,m doing this in a strategy by Selection object where I choose as target the 3800 RP. I thought that URS knows to send this call trough 3810 XRP by default.
How should I do it then? How should I send the call from 3601 (which is on Avaya) to 3800 on SIP?[/quote]
No, URS doesn't know that call should be routed to ExtRP as the way how call is transferred to remote site depends on ISCC configuration. Standard flow would be:

1/ URS sends RequestRouteCall (target: RP 3800 on SIP Server) to T-Server
2/ T-Server is configured to use ISCC so it sends request to SIP Server to establish ISCC transaction
3/ SIP Server receives the request and it reserves ExtRP 3810 for this transaction (let's assume here that ISCC route type 'route' is used)
4/ SIP Server sends response to T-Server that contains target number (Ext RP 3810)
5/ T-Server sends request to Avaya switch to transfer the call to number 3810 on SIP Server
6/ Call arrives to ExtRP 3810 on SIP Server side -> SIP Server processes the ISCC transaction (adds original UserData etc.)
7/ SIP Server routes to call to original target - RP 3800

In your case, the call flow is different as your URS is configured to handle ISCC instead of T-Server but it doesn't seem to work correctly.

You can find detailed description of ISCC in T-Server/SIP Server Deployment Guide in 'T-Server Common Functions and Procedures / Multi-Site Support' chapter.

R.

[vma]

Hi again Rene,
I changed 'use_extrouter' on URS to fals the first you mentioned so it's still on false. Still I don't get the attached data. I'm now trying to follow the flow you described trough my log files. The Avaya guy insists that in the he has to place a vector on 3810 to route the call to 3800. As your flow describes it, SIP does this not Avaya. Should he do this? Or should I tell him to remove this vector?

[René]

Hi,

External RP must be configured as any other Routing Point = vector must contain 'adjunct-route' and timeout. If Avaya routes the call instead of T-Server then the call flow is broken and ISCC won't work correctly.

BTW I'm a bit confused as you wrote in your first post that Ext RP 3810 is on SIP Server side (correct) and now you're saying it is on Avaya (incorrect)... Based on provided information you should see following call flow:

1/ EventRouteRequest on RP 3601 on Avaya
2/ RequestRouteCall to RP 3800 on SIP Server
3/ ISCC processing...
4/ RequestRouteCall to ExtRP 3810  on Avaya - T-Server sends request to Avaya switch
5/ EventRouteRequest on ExtRP 3810 on SIP Server (no strategy loaded on this ExtRP! - T-Server processes it internally)
6/ EventRouteRequest on RP 3800 on SIP Server

R.

[vma]

Rene you are pure gold
We managed to solve the issue. The guy on Avaya had our extrp replicated (with the same names) on avaya and he was routing the call directly to 3800 instead of routing it to extrp 3810 on SIP.
So flow is like this now and it works.

1/ call lands on Avaya 3601
2/ call is routed to Avaya 3810
3/ 3810 from Avaya is routed to 3810 from SIP
4/ 3810 from SIP is routed to 3800 from SIP - exactly where I wanted the call and has all attached data on it.

Thank you very much. I hope I we will meet once to get you drunk

[René]

Hi Mihai,

Good to heat that you made it working finally. I have 2 comments:

1/ [s]There is no need to have 3810 on Avaya side as ISCC should handle transfer (3800 Avaya -> 3810 SIP Server) by itself if interconnection between Avaya and SIP Server is configured properly[/s] Your configuration is incorrect as it stops working when you define more ExtRP on SIP Server side - ISCC will select one and would expect the call to arrive to this one. And there is no way to determine to which ExtRP the call should be sent to on Avaya side...

2/ I would recommend you to have separate numbering plan for Avaya and SIP Server. It's possible to use same numbers on both side but it may cause some issues in the future in case the configuration won't be done properly.

[i]Edit - I was thinking more about your "solution" and found it won't work correctly[/i]

R.

[vma]

For SIP ExtRP I have the 3 RPs, 3810, 3811 and 3812. As well I have 3 VDNs called the same (3810, 3811, 3812) on Avaya that are scripted "route-to *003810", "route-to *003811", "route-to *003812" (where *00 is prefix to go on SIP trunk, from AES to SES server). Every new SIP ExtRPs will have associated VDNs on Avaya scripted as above.
I choose 3 ExtRPs cause it will be a busy call center and it's possible to have more simultaneous calls. (As I understood more than 500 calls per hour).

Thank you again for your help!
Mihai

[René]

Hi Mihai,

In that case it may work but I don't see any reason for such configuration. If you specify access code '00' for SIP Server then T-Server can transfer the call itself and you won't need any extra VDN(s).

R.

[vma]

Indeed, now it's Avaya sending the call to the SIP side. It works and at least for the moment I will leave it like this. Go-Live is very near and still a lot things to do as always
The problem that remains is the ring back tone at agent level... Even if the agents are ready or not so MOH played or not, still I have no ring back. URS 'give_treatmet" optin is true, SIP's 'sip-ring-tone-mode' is 1... I need to investigate this today