Hello!
We have a next call-flow topology: User A -> FreeSWITCH -> Kamailio Fork -> Kamailio Edge => User(s) B, C, D, ... - FreeSWITCH adds X- header with a list of users to fork call (B, C, D legs). - Kamailio Fork generates branches via append_branch function towards Kamailio Edge. - Kamailio Edge keeps customer registration and sends BLF statuses (pua_dialoginfo).
The problem (or normal behavior by RFC) is that the dialog module on Kamailio Edge does not split these incoming legs into separated dialogs (incoming SIP Call-ID and from tag are the same). And as per my checking *kamcmd dlg.list_ctx* shows only the structure from the first leg and finally, it leads to a problem with BLF (as pua_diloginfo loses some SIP PUBLISHes).
Any advice on how to fix this is appreciated!
Hello! To simplify the question, how to force the dialog module to separate incoming calls that have the same callid and from_tag (forked by an upstream proxy)?
пт, 21 авг. 2020 г. в 19:12, Denys Pozniak denys.pozniak@gmail.com:
Hello!
We have a next call-flow topology: User A -> FreeSWITCH -> Kamailio Fork -> Kamailio Edge => User(s) B, C, D, ...
- FreeSWITCH adds X- header with a list of users to fork call (B, C, D
legs).
- Kamailio Fork generates branches via append_branch function towards
Kamailio Edge.
- Kamailio Edge keeps customer registration and sends BLF statuses
(pua_dialoginfo).
The problem (or normal behavior by RFC) is that the dialog module on Kamailio Edge does not split these incoming legs into separated dialogs (incoming SIP Call-ID and from tag are the same). And as per my checking *kamcmd dlg.list_ctx* shows only the structure from the first leg and finally, it leads to a problem with BLF (as pua_diloginfo loses some SIP PUBLISHes).
Any advice on how to fix this is appreciated!
--
BR, Denys Pozniak
-
Denys Pozniak