4 Dec
2015
4 Dec
'15
4:40 p.m.
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