Hello Simon, This sounds more like an issue with how Freeswitch is routing calls. However, a normal UAC will do something like this if the UAS doesn’t return a provisional (1xx) response in time. Are you sending a 100? If not, that could account for retransmissions. If instead it really is rolling back to OpenSIPs on a 503, it’s almost certainly some sort of routing issue on the Freeswitch side.
What’s the timing between the two INVITEs? If you could share a trace with some timestamps, that would help. -Brett On Tue, Jun 6, 2023 at 7:44 AM Simon Gajski via Users < [email protected]> wrote: > Hi > > I am using Opensips to act as SBC in combination with Freeswitch for > handling media. > I added function to count simultaneous incomming/outgoing calls per trunk. > > Call flow looks like: > > 1. Customer ---> Opensips > 2. Opensips ---> Freeswitch > 3. Freeswitch ---> Opensips > 4. Opensips ---> Carrier > > After call is returned from Freeswitch to Opensips (step 3), > routing logic is applied where the call shall be routed next (step 4). > > But before call is relayed to final route (in step 4) counter for > simultaneous calls > checks if either source or destination IP already reached its limit of > concurrent calls. > In case of yes, Opensips sends to Freeswitch 503 response instead of > performing step 4. > > send_reply("503", "Service Unavailable: Channel limit exceeded\n"); > exit; > > And here comes my problem: > Freeswitch ignores 503 message and sends another INVITE and then opensips > repeats its logic. > Can somebody tell me what should I check? or what would be the right way > to terminate such call? > > Thanks > > BR > Simon > > > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
