Hello

the main point here is how to match the source realm ,in order to make the appropriate decisions for an incoming request the source, or ingress, realm needs to be determined. The SBC may go through 4 steps:

1) The request comes through a specific Network Interface (slot, port and VLAN). If there is only one realm bound to this Network Interface the process is complete. However, the SBC supports Overlapping IP (OLIP) by allowing more than one realm to be bound to the same Network-Interface.

In this case –-> 2

2)  The SBC looks at the source IP address and compares it with the list of configured Session Agents’ IP addresses. If there is a match, the SBC takes the realm of the matching SA as the ingress realm.

Otherwise –-> 3

3)  The SBC looks at the packet’s ingress sip-port/sip- interface (i.e. destination address of the flow). A SIP interface is attached to a realm, so the process is complete, unless we have a case where nested realms share the same SIP-Interface.

In this case –-> 4

4)  The SBC looks at the source IP address and compares it with the addr-prefix parameter of all the realms. A match will finally determine the ingress realm.

Do u have configured SA on public side of your environment ? in that case ( step 2 ) did u configured the exact child realm on that SA ?

Is it an access-backbone scenario ? in that case ( step 4 ) did u have configured addr-prefix parameter on the child-realm with the source-ip address of the requesting endpoints ?

If both cases are not present , because there are no SA or because it's hard to recognize several dynamic source public addresses , u can consider to configure child realms with their own sip-interface , in that case it should fall in step 3 .

Hope it helps

Cheers

Antonio

Ok my scenario is this:

i. parent realm1 -  has 2 sip ports to the public. these sip ports have ip address x.x.x.x and y.y.y.y.

ii. then I defined child realm2 and realm3

now

iii. I want child realm2 to handle SIP requests towards sip port x.x.x.x and child realm3 to manage SIP requests towards sip port y.y.y.y

The aim therefore is to create local policy to split the request between the two child realms

eg  realm1 x.x.x.x [local-policy] realm2 --- >core network - A
       realm1 y.y.y.y [local-policy] realm3 --->core network - B

Hope this heps to better explain, if not I could paste snippnet of lab config

Thanks for reviewing.

Hello,

You can check with configuring different realm for User B and User C. Then enabled session-recording-server on realm C from where SBC is going to generate INVITE towards User C after refer.

Regards,
Ronak

this is on an ESBC 9.3

call comes in from our PSTN carrier and is sent via local policy to a system on a TLS/SRTP trunk. This call does not need to be (should not be) recorded.

Now, some of the calls are transferred back, via SIP REFER, and then go to a different system and this leg of the call needs to be recorded (SIPREC).

I can successfully route the call to its new destination (if it matters, I have refer-src-routing disabled) but I cannot get it to start the SIPREC. I'm thinking this is because the original call, before it came back via the REFER, never was recorded - ?

is there a way to enable SIPREC for the new leg of the call, after the SIP REFER?

thank you

Assuming the standard deployment of a call server setting up calls between sip phones, the SBC separating the two:
- sip phones on one side of the SBC - access
- call server on the other side of the SBC - core.
SIP/UDP is used between the SBC and the call server.
As the sip phones are behind NAT, HNT is used.

When SIP/UDP is used between the phones and the SBC, in case of a SBC HA failover, the active calls are maintained and if one side disconnects the call, the call is properly disconnected on the remote side too.

However, if I use SIP/TCP between the sip phones and the SBC, in case of a SBC HA failover, the calls are maintained but if one side disconnects the call, the remote side is not disconnected.
Traces shows that the call server receives the BYE message from the disconnecting side and send a BYE message to the remote side - via the SBC. However, the SBC replays 503 service unavailable - looks like if it doesn't know how to forward the call to the remote side - as if he lost the TCP connection.

Is this the expected behaviour from the SBC HA when using SIP/TCP ?
If not, any idea how I can get calls using SIP/TCP to behave like the calls using SIP/UDP and get disconnected properly ?

Tnx,
Dan

Hello

as already told u in the previous post LP-A is matching because To-address has priority over From-address , and in this case To-address is matching that ip address .

For this type of scenario what u can do is to configure cost=1 on LP-A , leaving cost=0 on LP-B , but I'm unaware of other type of traffic that u need to handle .

Cheers

Antonio