Basic call from sip server to avaya tserver

[cavagnaro]

Replace by no value? Guys help here, never did such thing.
And first rule of interconnectivity, never overlap dialing plans. You can't have 7XXX objects on both sides. If you do somehow you will have to assign a range. like 7[0-4] for Avaya and 7[5-9] for SIP Server...still ranges end up being very short unless you increment the 4 digit range.

For me that is the problem.

[hsujdik]

Replace by no value works fine usually (at least I have used it a lot without problems). But still, if he cant see the OPTION method on both sides and assuming he has oos-check and oos-force (or dont have a recovery-timeout), it might be network related or firewall related.

[cavagnaro]

Hummm...well yeah you are right. OPTIONS will travel to the contact IP and port.
Insist on network and don't trust customer. 99% of times, network guys will tell "not my problem" and then "opps...it was my problem".
Don't doubt or ask them, demand to check with you.

[ryusuf]

[quote author=cavagnaro link=topic=9043.msg42460#msg42460 date=1456838857]
Replace by no value? Guys help here, never did such thing.
And first rule of interconnectivity, never overlap dialing plans. You can't have 7XXX objects on both sides. If you do somehow you will have to assign a range. like 7[0-4] for Avaya and 7[5-9] for SIP Server...still ranges end up being very short unless you increment the 4 digit range.

For me that is the problem.


[/quote]

Hi Cavagnaro,

Yes even we have felt that the range should have been different like you said. If Genesys has a range starting with 7xxx then Avaya should have started with something else. However, this replace-prefix option works very well for removing the prefix. So ideally, if anyone from Genesys dials out using the prefix 9 then it should go out through the trunk.

If Genesys looks internally for this DN 7050 then i guess we shall get some message like [b]"Invalid Called DN"[/b].

Yesterday in our all day troubleshooting, we were able to notice something positive. Let me explain

1) A customer when dialing through the PSTN reaches the Avaya CM through Avaya Session Manager, and is routed to Genesys Route Point. Customer then hears the treatments from the Application loaded on the Route Point. When No agents are available to transfer the call, we have given a ForceRoute Block and to route the call to 97050 which is in Avaya. And this WORKS ! ! ! 

2) The second scenario is the one which i explained earlier also. When a agent logs into Genesys Workspace and dials 97050 out from the Genesys Workspace. The INVITE doesn't reach Avaya. 

The only difference between the two is, in the first scenario, a SIP REFER message is sent from Genesys to Avaya. And Avaya get's this message and responds back.
However, in the second scenario, a SIP INVITE message is sent, but it does not reach Avaya.

So literally, its like Genesys is telling to Avaya that "If you talk to me, i will respond back. But don't expect me to start the talk". This is what we see from the SIP OPTION message and the INVITE message. Both of which is initiated by Genesys and it is not reaching Avaya.

Now like you said, OPTIONS should travel to the IP and port if everything is clear, but something in the OPTION message or the INVITE message is not taking it to Avaya. 
But by the REFER message, it does reach Avaya. I have the SIP log for both these test call scenarios, and i couldn't understand the SIP messages much. 

I am actually looking a way to attach the log here, not pasting it. But attach the file. How do i attach a file?

Thank You
Best Regards

[cavagnaro]

Doesn't seems logic because even the TRoute command will need to use the trunk...
Post logs

[cavagnaro]

Upload to a third party server and share the link only here

[hsujdik]

Do you have an example of incoming message from Avaya? Maybe it uses tcp as transport and thus sip server can reply over the existing connection? Just a ling shot guess though

[ryusuf]

[quote author=hsujdik link=topic=9043.msg42492#msg42492 date=1456925990]
Do you have an example of incoming message from Avaya? Maybe it uses tcp as transport and thus sip server can reply over the existing connection? Just a ling shot guess though
[/quote]

Hi,

BRILLIANT CATCH !!!! 

That's the point. TCP was the one making us crazy.

When Genesys is sending INVITE it is in UDP, because the trunk is configured with [b]contact[/b] option [b]sip:192.168.10.144:5060[/b]

------------------When Agent Dials 97050 from Workspace------------------------

12:24:19.933: Sending  [b][0,UDP][/b] 625 bytes to 192.168.9.103:5060 >>>>>
INVITE sip:1000@192.168.9.103:5060 SIP/2.0
From: <sip:7050@192.168.10.191:5060>;tag=D497B6DA-A58D-4CB6-8F08-D61C4EFC8F65-517
To: sip:1000@192.168.10.191:5060
Call-ID: DB7CADC9-73AA-4D18-8976-9D4A1F82B73F-506@192.168.10.191
CSeq: 1 INVITE
Content-Length: 0
Via: SIP/2.0/UDP 192.168.10.191:5060;branch=z9hG4bK00FE621C-C046-4E2F-8833-CA2309376ADE-119
Contact: <sip:97050@192.168.10.191:5060>
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE
Max-Forwards: 70
X-Genesys-CallUUID: SF094SFU7P2IB49IMTUL1CK9AS000008
Session-Expires: 1800;refresher=uac
Min-SE: 90
Supported: timer
--------------------------------------------------------------------------------------

However, Avaya is communicating with TCP.

--------------------When Call is transferred from Genesys Application to Avaya------------

12:25:33.901: Sending [b] [240,TCP][/b] 991 bytes to 192.168.10.144:5060 >>>>>
REFER sip:112172412@192.168.10.123:5061;transport=tls;gsid=80fe019d-bbf1-4501-a5a1-56d00d670000 SIP/2.0
From: <sip:7002@jcci.com>;tag=D497B6DA-A58D-4CB6-8F08-D61C4EFC8F65-531
To: <sip:112172412@jcci.com>;tag=80fe19dbbf1e5167a156d0d6700
Call-ID: 80fe19dbbf1e5168a156d0d6700
CSeq: 1 REFER
Content-Length: 0
Via: SIP/2.0/TCP 192.168.10.191:5060;branch=z9hG4bK00FE621C-C046-4E2F-8833-CA2309376ADE-132
Contact: <sip:192.168.10.191:5060;transport=tcp>
X-Genesys-CallInfo: routed
Refer-To: <sip:7050@192.168.10.144:5060>
Referred-By: sip:7002@jcci.com
X-Genesys-CallUUID: SF094SFU7P2IB49IMTUL1CK9AS000009
Max-Forwards: 58
Route: <sip:204fa3d5@192.168.10.144;transport=tcp;lr>
Route: <sip:192.168.10.143:15060;transport=tcp;ibmsid=local.1456049537490_375367_375630;lr;ibmdrr>
Route: <sip:192.168.10.143:15061;transport=tls;ibmsid=local.1456049537490_375367_375630;lr;ibmdrr>
Route: <sip:204fa3d5@192.168.10.144;transport=tls;lr>
Route: <sip:192.168.10.123:5061;transport=tls;lr>

-------------------------------------------------------------------

So i changed the trunk configuration by explicitly adding the transport=TCP

[b]contact=sip:192.168.10.144:5060;transport=TCP[/b]


Appreciate the support of everyone to help find this out. Especially hsujdik and cavagnaro (Sorry don't know both of your's actual name  )

Thank You
Best Regards

[Kubig]

Avaya -- OMG

Genesys SIP allows to accept SIP messages transported via both protocol - UDP/TCP. Of course, the default protocol is UDP as is designed. Great, the solution was found.
Prerequisities like these elementary default network and application configuration should be checked and filled before integrate/deploy anything to the live environment.

[cavagnaro]

And why on earth did the TRoute worked then??? O.o

[hsujdik]

It is probable because when RequestRouteCall  is sent to SIP Server, it would reuse the existing TCP connection when talking back to Avaya

[cavagnaro]

Not buying that one buddy...That would send a new INVITE, must be something else

[hsujdik]

That probably would depend on the oosp-transfer-enabled option being set to true or false (and, I suppose it is set to true, because it works and because he mentioned REFER being used). So, SIP Server would reply back 302/Moved Temporarily on the same dialog instead of starting a new dialog.

[cavagnaro]

Hummm makes sense...