SIP traffic - minor issue with OPTIONS messages

 

Hello Steve,

 

 

Based on our previous discussion i suggested to do following scenarios:

 

 

1) to leave only one SIP monitor(on LB) and change existing one on MSS (tcp monitor).

 

 

2) On LB I will mark both Rhino servers to be "down" and see what happens. Maybe to check if LB would throw alarm on MSS...

 

 

I will give you part of discussion we had. (Person A is me, person B is MSS guy).

 

 

B: I guess option 2 would mean that we get no response to INVITE's and thus cause calls to fail with CC920 (SIP control Plane failure)

 

A: yea, something like this would be expected

 

B: we have to send the SIP OPTION's message to the same address that we send the INVITE .. so is Option 1 feasible ?

 

A: so basically without SIP monitor on your side, you are unable to send any traffic to LB, right?

 

B: no .. we can disable SIP OPTION's completely if required .. it just means we would have no prior knowledge that the SIP endpoint is down (and no way of alarming this)

 

A: so you don't have any other way, except SIP OPTIONS, to interogate LB availability?

 

B: no... unless we use SIP over SCTP ?

 

B: we would just get clear codes showing that SIP calls are failing

 

 

I think our BIG-IP 1600 on 10.2.4 supports SIP over SCTP, but i have to see how this will affect our config and whether we will be able to achieve.

 

For time being i switched SIP monitor on LB with tcp check, just not to duplicate SIP traffic on Rhino servers.

 

 

Any comments on this?

 

 

Regards,

 

Zvone

 

 

Sorry for the delay in responding. So, the F5 supports SIP over SCTP but this puts you back to the original situation where you are monitoring twice and the monitoring traffic from the MSS servers is being load balanced to one or other of the Rhino servers.

 

 

It's really not clear to me what you/they are trying to achieve. You have a load balanced 'service' for the Rhino servers, assuming you are happy with the LB to Rhino monitors then the MSS servers only need to check that the LB VIP is up, if it is then at least one of the Rhino servers is up and all is well right? Things will work?

 

 

Using functional monitors on the MSS servers seems somewhat wrong as the monitor traffic might go to a different Rhino server than any 'real' traffic. Do you see my point? As long as the LB VIP is up, there will be service as at least one Rhino server is up. If the VIP isn't up, the monitoring doesn't matter anyway because both Rhino servers are down and nothing will work.

 

 

Perhaps I'm missing some detail here? What are you doing regarding persistence? Whats the LB method? Sounds like a basic tcp monitor is not possible right?

Hey Steve,

 

 

This MSS is NSN's equipment and it is black box to me, but as I mentioned in last post the MSS guy said that it does make a difference if we use SCTP. This way he can avoid using SIP OPTIONS messages from MSS to LB (don't know how exactly, like i said it is black box to me). In the last post I also put explanaton that with current config he simply cannot send any SIP traffic to LB if prior he doesn't send at least one OPTIONS message, and this is the reason whis we still have SIP monitor on MSS.

 

 

I got your point and i couldn't agree more, but customer is always right. This issue is minor and very stupid, but still i have to investigate it.

 

 

I guess there is no point anymore to ask so many questions, we are going in circle here. The only remaining possibility for us is to try SCTP suggestion and see what will happen.

 

Once more many thanks for all your answers and time.

 

 

Regards,

 

Zvone

Hey Zvone, I know what you mean. You're welcome and thanks for stretching my mind a bit. If the SCTP works (somehow) please do let us know. Cheers

Hello Steve,

 

 

Just to update the topic. In the end we didn't try SIP via SCTP as this is out of the question on this project, so we are still stuck with UDP.

 

 

There were some suggestions from NSN experts so i will just post their observations (if this will mean anything to anyone):

 

 

"Virtual IP (VIP) address concept is introduced for the load balancer in MSS.

 

For DX units, it means unit doesn’t answer to ARP requests pointed to that IP. For LinDX unit it doesn’t makes difference

 

The SIP VIP is for TCP/UDP. SCTP (H.248) requires different VIPs.

 

The traffic from adjacent element is routed to the MSS external IP address which is actually the IPDU unit’s IP address. It is Logical address, which means it is transferred during SWO.

 

The IPDU forwards the SIP packets to CCSU/SIGU/SCPU units based on their unit specific IP addresses using L2 routing (MAC address).

 

The SIP traffic from the CCSU/SIGU/SCPU units is routed to the IPDU unit by configuring source IP address based default gateway.

 

Only SIP (and possibly H.248) shall be routed via LB / IPDU.

 

One logical IP address per working IPDU unit. Used as Local IP address based default GW of the 32 bit VIP address in SIGU/CCSU/SCPU. Static routes, inc. default gateway, are never configured via IPDU.

 

One physical IP address per SIGU/CSSU/SCPU, including spare unit. For each IPDU, One physical IP address per WO-EX IPDU (also for spare) for internal backup data.

 

One logical IP address for LDAP client, used by the signalling unit.

 

 

I think you have licence in place, so this is just to mention here that "SIP Loadbalancer in MSS license" is needed. Afterwards you can enable SIPLB_OLC_CONTROL PRFILE parameter (Parameter class: 12, Parameter id: 126) which is:

 

This parameter indicates whether the new OLC method (Window Access Control (WAC)) for SIP load balancers is used. The SIP access gates should be on VIP (virtual IP address of the unit) basis. IPDUs could be made as protected units."

 

 

The answer to that was:

 

"The ATCA MSS (for this customer) is not using the IPDU as Load Balancer feature yet, as it is running M16.0 EP1. Therefore SIP traffic is routed at L3 through the IPDU (as L3 routing point) and onto the GISU (signalling units) on the MSS."

 

 

BR

 

Zvone

Thanks Zvone. Means nothing to me! =]