[SR-Users] why is rtpenengine-delete deleting the whole call?

[Richard Fuchs]

On 12/03/2015 06:38 PM, Juha Heinanen wrote:
> i noticed one more things during testing of rfuchs/delete-branch, which
> i don't quite understand.
>
> the test call is parallel forked to two destinations and offer (using
> via-branch=1) is issued for both.  thus the offers have the same params:
>
> ... "call-id": "138d9b5516741c30", "via-branch": "z9hG4bKe8998a18295855da", "received-from": [ "IP4", "192.98.102.10" ], "from-tag": "b5b2ffd6a2205b13", "command": "offer" }
>
> ..."call-id": "138d9b5516741c30", "via-branch": "z9hG4bKe8998a18295855da", "received-from": [ "IP4", "192.98.102.10" ], "from-tag": "b5b2ffd6a2205b13", "command": "offer" }

That doesn't work. The point of the via-branch handling is to recognize 
that this is a forked call/offer and so the via-branch should be 
different in the two offers. Right now this only works if the call is 
forked in a second SIP proxy instance daisy-chained before the one doing 
the RTP proxy stuff, as Kamailio offers no mechanism to anticipate the 
next outgoing via-branch value. Fixing this is on our to-do list.

> question: how it is possible the call works, i.e., rtpengine still has
> the call even when it was already deleted?  does it remember that two
> offers were made using same params and the call does not really get
> deleted before it has received two deletes?

It still works if the answer comes in before the delete-delay triggers 
actual deletion (which is the reason for delete-delay's existence). It's 
also necessary that both offers were made with the same parameters, e.g. 
not one with RTP and the second the SRTP (otherwise rtpengine could get 
confused).

Cheers