[SR-Users] why is rtpenengine-delete deleting the whole call?
rfuchs at sipwise.com
Fri Dec 4 15:40:18 CET 2015
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", "18.104.22.168" ], "from-tag": "b5b2ffd6a2205b13", "command": "offer" }
> ..."call-id": "138d9b5516741c30", "via-branch": "z9hG4bKe8998a18295855da", "received-from": [ "IP4", "22.214.171.124" ], "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
More information about the sr-users