Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SBCE link shows down in SM 1

Status
Not open for further replies.

mjm23

Technical User
Jul 1, 2020
80
PH
Hi, I just setup an SBCE and integrated it to our SM. When I checked the status of the connection in SM, it shows down. Both interfaces (A1 and SM100) can ping each other. I used the same port, 5070 via TCP. When I checked the server status in SBCE, it shows the link to SM is UP. not sure what is happening. I haven't connected the SBCE to a SIP service provided yet as they are not ready.

[pre][tt]----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SBCE
SM100
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
13:59:38.760 |<--OPTIONS-| | | (282) sip:10.117.113.35:5070
13:59:40.763 |--Request->| | | (274) 408 Request Timeout
14:00:08.759 |--OPTIONS->| | | (3) sip:sip.mydomain.com
14:00:08.761 |<--200 OK--| | | (3) 200 OK (OPTIONS)
14:00:08.761 |<--OPTIONS-| | | (290) sip:10.117.113.35:5070
14:00:10.763 |--Request->| | | (282) 408 Request Timeout
14:00:38.760 |--OPTIONS->| | | (3) sip:sip.mydomain.com
14:00:38.761 |<--200 OK--| | | (3) 200 OK (OPTIONS)
14:00:38.762 |<--OPTIONS-| | | (294) sip:10.117.113.35:5070
14:00:40.765 |--Request->| | | (290) 408 Request Timeout
14:01:08.761 |--OPTIONS->| | | (3) sip:sip.mydomain.com
14:01:08.762 |<--200 OK--| | | (3) 200 OK (OPTIONS)
14:01:08.763 |<--OPTIONS-| | | (307) sip:10.117.113.35:5070
14:01:10.766 |--Request->| | | (294) 408 Request Timeout
14:01:38.762 |--OPTIONS->| | | (3) sip:sip.mydomain.com
14:01:38.763 |<--200 OK--| | | (3) 200 OK (OPTIONS)
14:01:38.764 |<--OPTIONS-| | | (314) sip:10.117.113.35:5070
14:01:40.766 |--Request->| | | (307) 408 Request Timeout
14:02:08.763 |--OPTIONS->| | | (3) sip:sip.mydomain.com
14:02:08.764 |<--200 OK--| | | (3) 200 OK (OPTIONS)
14:02:08.765 |<--OPTIONS-| | | (323) sip:10.117.113.35:5070
14:02:10.767 |--Request->| | | (314) 408 Request Timeout
14:02:38.763 |--OPTIONS->| | | (3) sip:sip.mydomain.com
[/tt][/pre]
 
The 408 timeout is the problem.

Any SIP response to an options ping is ok. 408 means nothing came back. Presumably that's because of your SBC configuration.

Don't worry about it. When the carrier trunk comes up, you'll be fine. Or, you can set out of dialog message handling in one of the profiles to block options from SM with 200OK and SM will show happy.
 
thanks for the response. I will update this post once the carrier has activated their SIP trunk.
 
It surprised me when I was setting up my first SBCE to learn that the default behavior of all SBCs is to forward ALL requests. So when ASM sends an OPTIONS request towards the SBCE, the SBCE simply forwards it out the other side to the SIP Trunking Provider's SIP Proxy. In my experience, Providers want to do as little as possible and so they typically do not respond to OPTIONS requests. That may explain why you are getting a 408 Response Timeout.

I recommend changing the default behavior of the SBCE so that it does respond to OPTIONS heartbeats. That way, ASM has an additional way to know if the SBCE is alive or dead and might make alternate routing decisions, perhaps to SBCE-2.

To do so, within the SBCE change the Signaling Rule that you are using in your Server Flow to ASM. Within the rule, for OPTIONS requests have it BLOCK the request and respond with a 200 OK. Do that for both in-dialog and out-of-dialog requests.

Also, within the SBCE when setting up ASM-1 as a SIP Server, configure the SBCE to send OPTION heartbeat requests towards ASM every 30 seconds. That way the SBCE has an additional way of learning if ASM-1 is alive or dead, and could use that to decide to fail over to ASM-2. (That failover is configured in the Routing Policy.)
 
I'm not a fan of blocking with 200 OK. They all log as incidents making the incident viewer worthless
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top