[SR-Users] How to handle BYE in case of serial fork

Björn Klasen bklasen at tng.de
Fri Sep 11 10:46:27 CEST 2020


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

T +49 431/ 530530
F +49 431/ 7097-555
mailto: bklasen at 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

More information about the sr-users mailing list