[SR-Users] How to handle BYE in case of serial fork
Henning Westerholt
hw at skalatan.de
Fri Sep 11 11:47:41 CEST 2020
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 <sr-users-bounces at lists.kamailio.org> On Behalf Of Björn Klasen
Sent: Friday, September 11, 2020 10:46 AM
To: sr-users at lists.kamailio.org
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 at P1->| | |
| |--INV Bob at B--->| |
| |<-100----------| | <-100----------|
|| |
| |<-180 TT1------| |
|<-180 TT1------| | |
Forward after 10 seconds
| |--CANCEL------>| |
| |<-487----------| |
| |<-200 OK-------| |
| |--ACK--------->| |
|<-181 TT1------| | |
| |--INV Carol at 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: bklasen at tng.de
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
sr-users at lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
More information about the sr-users
mailing list