Register request is not sent to Carriers

[vcidst]

I've used jambonz-helm-charts to create the cluster on kubernetes, I notice that the register request is not sent to carriers when new carriers are added that require SIP registration

Confirmed with the sip registration logs from homer-webapp

[vcidst]

Observation: Logs of sbc-register register app on my cluster is completely empty

I'm assuming this requires some changes in other apps that should be making a call to sbc-register. I just checked redis too and there are no active registrations

[davehorton]

There are two issues here:

1. While is sort of works in the plain EC2 deployments, there is a bug there as well. The problem is that when you run multiple SBC SIP servers, all of them will send REGISTERs for all trunks that require registers. This leads to a problem because most SIP providers expect to see a single source IP for the registers.
2. It doesn't work at all in a K8S deployment, because the sbc-registrar app is using an outbound connection to drachtio server and thus cannot initiate a REGISTER request.

I recomend we address both issues, by doing the following:

• move the entire outbound registration logic from sbc-registrar to sbc-outbound-handler. This is because the latter is a sidecar app in K8S which is always runnning on the drachtio-server pod with an inbound connection to drachtio, thus is well-positioned to initiate REGISTER requests
• We need a way to divide the trunks requiring outbound register among the available SBC SIP servers, so that for a given trunk one and only one SIP server is sending the REGISTERs. The information in redis about the available SBC-SIP servers (written there by sbc-inbound or -outbound I think) will be useful in this. On startup, the sbc-options-handler needs to somehow "claim" 1/N of the trunks requring register, given N SBC SIP servers.
• Finally, when we send an outdial INVITE (via Dial or REST) out a SIP trunk that has registered, it will need to go out the specific SBC that is registering for that trunk. This needs to be handled similarly to when we deliver a call to a registered SIP device, where sbc-outbound determines the device is registered against a different SBC and responds with a 302 Redirect to get the call over there

[davehorton]

In thinking more about this, it is not necessary that the outbound registration load is "dviided" between the available SBC SIp servers. It would be fine (and simpler) if they were all handled by a single SBC. This could be simply achieved by having the app look up from redis on startup the list of SBC SIP public IPs and compare its own public IP to the first in the list -- it it was first in the list (or no list was found at all, which will be the case with the jambonz mini I think) then it would designate itself as the one to the do registering.

Carriers/trunks that do require registration, and for which we have successfully registered, will need a key written in redis (something with carrier_sid) so that sbc-outbound when dialing out to a carrier can check if such a record exists, if so it should retrieve an associated hash including the public ip of the sbc sip server doing the registration; if found, compare to its own IP and redirect to the other IP if not matching (this is the part that is similar to how we redirect calls to sip devices)

[vcidst]

It would be fine (and simpler) if they were all handled by a single SBC

Would that not imply that the all the traffic from a selected carriers which require registration will be handled by only a single server? It might introduce scaling issues -- however I think since SIP Servers can handle a lot more throughput than RTP nodes so it should be okay

I've been going through the repo jambonz/sbc-outbound but I think I'll need some help. We can start whenever you're back from vacations. Do you think it'll be possible to fix this issue in the coming 2 weeks?

[juansalvatella]

@vcidst I’ll be happy to participate in any testing or development effort required to help on this