Hello Björn, if I understood your scenario correct: what about just forwarding the BYE normally? It should be usually routed as in-dialog request without any transaction matching. What do you mean with "Kamailio doesn't know anything about it, so it does not reply".
BTW, you should think about upgrading your Kamailio. 😉 Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com -----Original Message----- From: sr-users <[email protected]> On Behalf Of Björn Klasen Sent: Friday, September 11, 2020 10:46 AM To: [email protected] Subject: [SR-Users] How to handle BYE in case of serial fork Hi we are using Kamailio 4.3.7 and I have a question concerning BYE handling. We have the following situation: A carrier a call to us. We are forwarding the call to the destination, but it does not pick up the call. We have call-forward active with use of tm module, so we forward the call to the new destination. The first call generates a to-tag in 180, let's call it TT1. The second call, so the c-destination also answer with 180 but with another to-tag (TT2). Both ringing are passed to the originating carrier. When the timer for the first call is timed out, Kamailio cancels the branch with a CANCEL so it does not exist any more Now the c-destination picks up the phone, and reply with 200 OK with TT2 The carrier then sends a BYE with TT1 to us, but Kamailio doesn't know anything about it, so it does not reply and the carrier sends a timeout and terminates the complete call. So the question is, how handle such a situation. Is it possible to store the first branch, or fake a OK reply to the BYE request of the carrier as for my understanding this behaviour is not against RFC. To clarify the situation here comes a call-flow diagram A Kamailio B C |---INV Bob@P1->| | | | |--INV Bob@B--->| | | |<-100----------| | <-100----------| || | | |<-180 TT1------| | |<-180 TT1------| | | Forward after 10 seconds | |--CANCEL------>| | | |<-487----------| | | |<-200 OK-------| | | |--ACK--------->| | |<-181 TT1------| | | | |--INV Carol@C----------------->| | |<-100--------------------------| | |<-180 TT2----------------------| |<-180 TT2------| | | | |<-200 OK TT2-------------------| |<-200 OK TT2---| | | --BYE TT1----->| || | --BYE TT1----->| | | |--BYE TT1----->| | | |--408--------->| | | |--ACK--------->| | | | |--ACK------------------------->| | |<-BYE TT2----------------------| <-BYE TT2------| || |--481--------->| | | |--481------------------------->| To get around the the situation with the second to-tag, we passing every call through SEMS now, because its B2B function rewrites the to-tag, so there is always only one to-tag towards the carrier A. But it's not the gold solution. I hope somebody can help me. BR, Björn -- Björn Klasen, Specialist TNG Stadtnetz GmbH, Network Management (VoIP) Projensdorfer Straße 324 24106 Kiel Germany T +49 431/ 530530 F +49 431/ 7097-555 mailto: [email protected] http://www.tng.de Register: Amtsgericht Kiel HRB 6002 KI Executive board (Geschäftsführung): Dr.-Ing. Volkmar Hausberg, Sven Schade, Carsten Tolkmit, Dr. Sven Willert Tax-Id (Steuernr.): 2029047020, VAT-Id (USt-Id): DE225201428 _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
