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