You have to fixed that:
From the wireshark traces running on SIP server, i can see that SIP OPTION messages are sent to the Avaya Session Manager. However, the SM did not receive it. And after the OOS timeout for not receiving the SIP 200 OK, it forces the trunk to go OUT OF SERVICE. I believe this is why, the call is not going out from the trunk.
Hi Kubig/Cavagnaro,
Thanks for the response
As per the client, there is no firewall between the Genesys SIPS and Avaya SM.
This option messages are not reaching at all to the Avaya SM from the Genesys SIPS. However, the OPTION messages from Avaya SM is reaching Genesys SIPS and responding back with 200 OK.
Since the customer is sticking that there is no firewall between the two. The questions which are running over the head is
What can be the other reasons why the OPTION messages or the INVITE messages are not reaching the Avaya SM?
Thank You
Best Regards
[ol]- Network
Hi Kubig,
For sure, its not Genesys end?
Anything to do with Request-URI, or SIP headers etc.. I am least knowledgeable on SIP related things. Spare me if am asking something lame.
For Genesys to connect to Avaya CM using Avaya Session Manager, we just have to create a Trunk DN at the Genesys end with the options which i have mentioned? And a dial plan at the Avaya SM right?
Thank You
Best Regards
Rashid
Did you configure the “request-uri” on trunk DN related to the AvayaSM? If yes, what is the current configuration and why this options was configured?
See SIP logs, to where are these packets being sent? Something must be wrong on your configuration or network.
Conf: bad ip, bad port
Net: something blocking traffic. as per ISO layers you know that software doesn’t handle transport, what does it? Yeah…physical layer, meaning? LAN. So check your LAN. Only way software can affect if by a firewall or a bad network configuration like a bad gateway.
Can you telnet Avaya SIP port from Genesys server?
Does the host where the sip server resides has a route to the avaya sm subnet, on the signaling network card?
Hi Kubig,
No i haven’t configured “request-uri” on trunk DN. The trunk DN configuration is as below
[TServer]
contact = sip:192.168.10.144:5060
oosp-transfer-enabled = true
prefix = 9
refer-enabled = false
replace-prefix =
As per the Avaya SM engineer, they use a Domain name. But how do we configure that domain name in the Genesys trunk DN?
Hi Cavagnaro,
The SIP request is as follows INVITE sip:7050@192.168.10.144:5060.
Here 7050 is the DN in the Avaya CM which i am trying to dial from Genesys and 192.168.10.144 is the Avaya SM which is configured in the trunk as mentioned above.
Both Genesys server and the Avaya SM are on the same subnet and as per the client, there is no firewall between these. However, i shall double check and verify with the network team again.
Yes i am able to telnet Avaya SIP port 5060 from the Genesys SIP server.
Hi,
Yes both of them are on the same subnet.
Thank You
Best Regards
Wait, number is 7050 and prefix is 9??? Create another trunk with prefix 7
Hi Cavagnaro,
Prefix 9 is set on the trunk and i have also set the option replace-prefix to remove it while passing out of Genesys. That is why when i dial 97050 from the Genesys workspace, the INVITE message is only passing 7050.
Correct me if i am wrong. And also, i have Genesys routing points starting with 7, so is it good to create a trunk with prefix 7?
Thank You
Best Regards
??? 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.
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.
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.
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 “Invalid Called DN”.
Yesterday in our all day troubleshooting, we were able to notice something positive. Let me explain
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 ! ! ! 
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
Doesn’t seems logic because even the TRoute command will need to use the trunk…
Post logs
Upload to a third party server and share the link only here
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
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 contact option sip:192.168.10.144:5060
------------------When Agent Dials 97050 from Workspace------------------------
However, Avaya is communicating with TCP.
--------------------When Call is transferred from Genesys Application to Avaya------------
12:25:33.901: Sending [240,TCP] 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:[email removed]>;tag=D497B6DA-A58D-4CB6-8F08-D61C4EFC8F65-531
To: <sip:[email removed]>;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:[email removed]
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
contact=sip:192.168.10.144:5060;transport=TCP
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
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.
And why on earth did the TRoute worked then??? O.o