SBC Page - Home




ACKs to 2xx-class messages are sent to the remote target of the dialog.

==========================================

R-URI of the ACK needs to match the Contact-URI in the 200 OK

==================================================================

the SBC  --   when there is a RR the ack will go to the IP in the RR.
If there is no RR the ack will go to the IP in the Contact header.

========================================================================================

The ACK has a bad to-tag.

There is no 4xx response to ACK but it is coming with bad To tag causing dialog mismatch:

200-OK :
from: "S Mazo";tag=f4cc0548-01d6-0022-1961-00e0bbb338b9
to: ;tag=SDa1r9099-gK06f30586 <---

ACK :
from: "S Mazo";tag=f4cc0548-01d6-0022-1961-00e0bbb338b9
to: ;tag=gK048ddb91 <=====

===================================================================================

 

The SD is almost certainly not forwarding the ACK because it does not know how to resolve the remote target, sip:+358504803228@fi-pgw1.ipt.ip.tele.dk:5060.

Unfortunately you didn't include a configuration so we cannot confirm whether or not your DNS settings are configured properly on the SBC.
Are you sure this address is resolvable given your DNS domain? Have you looked into any DNS problems or was this only identified as an SBC problem?

===============================================================================

 

The ACK was being rejected by the SD because it was not conformant to RFC 3261 (it had an additional "Require" header that was not present in the INVITE).

Because ACKs are the only transaction in SIP that do not have a final response, there was no visible evidence that the SD was rejecting it -- say, with a 420 Bad Extension -- but instead the ACK died silently inside the SD's SIP stack.
As a workaround for the invalid signaling  , configure a sip-feature to allow the Require header to pass through; he has confirmed the call now works and the logs confirm the behavior is as expected.

The asterisk box is violating RFC 3261.

The INVITE from the asterisk has a "Supported: replaces, timer" header in it. The 200 OK comes back from the NBS with "Require: timer", and the ACK from the asterisk has "Require: timer". This is a violation of RFC 3261 section 8.2.2.3:

An ACK request for a 2xx response MUST contain only those Require and
Proxy-Require values that were present in the initial request.

 
sip-feature
name timer
realm
support-mode-inbound Pass
require-mode-inbound Pass
proxy-require-mode-inbound Pass
support-mode-outbound Pass
require-mode-outbound Pass
proxy-require-mode-outbound Pass

Leave the realm name blank as  above.
============================================

NOTE:

from guide:
19. uri-fqdn-domain—Change the host part of the URIs to the FQDN value set here. If set to enabled, and used
with an FQDN domain/host, the requests generated by the Oracle Enterprise Session Border Controller on this SIP
interface will have the host part of the URI set to this FQDN value. Only the Request, To, and From URIs are
changed. After the dialog is established, the URIs are not changed.