in my test sip proxy parallel forks the invite to two contacts and two rtpengine-offers are made with these kind of call-id and via-branch params:
"call-id": "f33a7e21c57edbf3", "via-branch": "z9hG4bK79d6.d19587ffadd9f72bca61d9578eb12bd9.0" "call-id": "f33a7e21c57edbf3", "via-branch": "z9hG4bK79d6.d19587ffadd9f72bca61d9578eb12bd9.1",
then the via-branch .0 callee answers and rtpengine-answer is sent to with this kind of call-id and via-branch params:
"call-id": "f33a7e21c57edbf3", "via-branch": "z9hG4bK79d6.d19587ffadd9f72bca61d9578eb12bd9.0",
after that sip proxy deletes the other branch by sending rtpengine-delete with this kind of params:
Nov 27 02:25:55 lohi rtpengine[3792]: [f33a7e21c57edbf3] Received command 'delete' from 127.0.0.1:40700 Nov 27 02:25:55 lohi rtpengine[3792]: [f33a7e21c57edbf3] Dump for 'delete' from 127.0.0.1:40700: { "call-id": "f33a7e21c57edbf3", "via-branch": "z9hG4bK79d6.d19587ffadd9f72bca61d9578eb12bd9.1", "received-from": [ "IP4", "127.0.0.1" ], "from-tag": "3322319973f3909e", "command": "delete" }
and rtpengine responds:
Nov 27 02:25:55 lohi rtpengine[3792]: [f33a7e21c57edbf3] Response dump for 'delete' to 127.0.0.1:40700: { "created": 1448583951, "last signal": 1448583955, "tags": { "3322319973f3909e": { "tag": "3322319973f3909e", "created": 1448583951, "in dialogue with": "0f6759297b8f1711", "medias": [ { "index": 1, "type": "audio", "protocol": "RTP/AVP", "streams": [ { "local port": 53864, "endpoint": { "family": "IPv4", "address": "192.98.102.10", "port": 10458 }, "advertised endpoint": { "family": "IPv4", "address": "192.98.102.10", "port": 10458 }, "last packet ... Nov 27 02:25:55 lohi rtpengine[3792]: [f33a7e21c57edbf3] ... ": 1448583951, "flags": [ "RTP", "filled" ], "stats": { "packets": 0, "bytes": 0, "errors": 0 } }, { "local port": 53865, "endpoint": { "family": "IPv4", "address": "192.98.102.10", "port": 10459 }, "advertised endpoint": { "family": "IPv4", "address": "192.98.102.10", "port": 10459 }, "last packet": 1448583951, "flags": [ "RTCP", "filled" ], "stats": { "packets": 0, "bytes": 0, "errors": 0 } } ], "flags": [ "initialized", "send", "recv" ] } ] }, "0f6759297b8f1711": { "tag": "0f6759297b8f1711", ... Nov 27 02:25:55 lohi rtpengine[3792]: [f33a7e21c57edbf3] ... "via-branch": "z9hG4bK79d6.d19587ffadd9f72bca61d9578eb12bd9.0", "created": 1448583951, "in dialogue with": "3322319973f3909e", "medias": [ { "index": 1, "type": "audio", "protocol": "RTP/AVP", "streams": [ { "local port": 53844, "endpoint": { "family": "IPv4", "address": "10.0.2.15", "port": 10144 }, "advertised endpoint": { "family": "IPv4", "address": "10.0.2.15", "port": 10144 }, "last packet": 1448583951, "flags": [ "RTP", "RTCP", "filled" ], "stats": { "packets": 0, "bytes": 0, "errors": 0 ... Nov 27 02:25:55 lohi rtpengine[3792]: [f33a7e21c57edbf3] ... } }, { "local port": 53845, "endpoint": { "family": "IPv6", "address": "::", "port": 0 }, "advertised endpoint": { "family": "IPv6", "address": "::", "port": 0 }, "last packet": 1448583951, "flags": [ "RTCP", "fallback RTCP", "filled" ], "stats": { "packets": 0, "bytes": 0, "errors": 0 } } ], "flags": [ "initialized", "send", "recv", "rtcp-mux" ] } ] } }, "totals": { "RTP": { "packets": 0, "bytes": 0, "errors": 0 }, "RTCP": { "packets": 0, "bytes": 0, "errors": 0 } }, "result": "ok" }
which then results in deletion of the whole call, i.e., also the branch that answered.
question: why does rtpengine not do what it is asked to do in rtpengine-delete, i,e. delete the offer corresponding to "call-id": "f33a7e21c57edbf3", "via-branch": "z9hG4bK79d6.d19587ffadd9f72bca61d9578eb12bd9.1"?
-- juha
On 11/26/2015 07:39 PM, Juha Heinanen wrote:
question: why does rtpengine not do what it is asked to do in rtpengine-delete, i,e. delete the offer corresponding to "call-id": "f33a7e21c57edbf3", "via-branch": "z9hG4bK79d6.d19587ffadd9f72bca61d9578eb12bd9.1"?
Because the via-branch isn't taken into account for the delete. I thought I already explained that just recently?
Cheers
Richard Fuchs writes:
question: why does rtpengine not do what it is asked to do in rtpengine-delete, i,e. delete the offer corresponding to "call-id": "f33a7e21c57edbf3", "via-branch": "z9hG4bK79d6.d19587ffadd9f72bca61d9578eb12bd9.1"?
Because the via-branch isn't taken into account for the delete. I thought I already explained that just recently?
Sorry about the confusion. I thought that the previous one was about via-branch extra value.
So via-branch will be taken in account in some future version of rtpengine without a need to use extra value?
-- Juha
On 11/26/2015 09:21 PM, Juha Heinanen wrote:
Richard Fuchs writes:
question: why does rtpengine not do what it is asked to do in rtpengine-delete, i,e. delete the offer corresponding to "call-id": "f33a7e21c57edbf3", "via-branch": "z9hG4bK79d6.d19587ffadd9f72bca61d9578eb12bd9.1"?
Because the via-branch isn't taken into account for the delete. I thought I already explained that just recently?
Sorry about the confusion. I thought that the previous one was about via-branch extra value.
So via-branch will be taken in account in some future version of rtpengine without a need to use extra value?
Correct.
To clarify: the extra-pv parameter simply replaces the via-branch value with a custom string.
Cheers
On 11/27/2015 07:41 PM, Juha Heinanen wrote:
Richard Fuchs writes:
To clarify: the extra-pv parameter simply replaces the via-branch value with a custom string.
Got it and when standard via-branch value is taken into account that would be enough for me at least for now.
I have a prospective fix in a separate branch: https://github.com/sipwise/rtpengine/tree/rfuchs/delete-branch
Can you please test it to see if it works for your use case, then I'll merge into master.
Cheers
Richard Fuchs writes:
I have a prospective fix in a separate branch: https://github.com/sipwise/rtpengine/tree/rfuchs/delete-branch
Can you please test it to see if it works for your use case, then I'll merge into master.
Richard,
I had chance to test this branch and it worked as I expected. With earlier version these two offers:
... call-id": "2abe9a5db43054dc", "via-branch": "z9hG4bK1b77.e8d0221e5eb3296ab02b6572ffbb5b71.1", "received-from": [ "IP4", "127.0.0.1" ], "from-tag": "9f7bfa64b244d4c9", "command": "offer" }
... "call-id": "2abe9a5db43054dc", "via-branch": "z9hG4bK1b77.e8d0221e5eb3296ab02b6572ffbb5b71.0", "received-from": [ "IP4", "127.0.0.1" ], "from-tag": "9f7bfa64b244d4c9", "command": "offer" }
followed by delete
Dec 3 12:17:53 lohi rtpengine[6019]: [2abe9a5db43054dc] Dump for 'delete' from 127.0.0.1:41419: { "call-id": "2abe9a5db43054dc", "via-branch": "z9hG4bK1b77.e8d0221e5eb3296ab02b6572ffbb5b71.1", "received-from": [ "IP4", "127.0.0.1" ], "from-tag": "9f7bfa64b244d4c9", "command": "delete" }
resulted in this:
Dec 3 12:17:53 lohi rtpengine[6019]: [2abe9a5db43054dc] Scheduling deletion of call branch '9f7bfa64b244d4c9' in 30 seconds
Using the above branch, these two offers
... "call-id": "d07e00c875f64161", "via-branch": "z9hG4bKe298.e03e6127f4e4ac3a82a67f02c6453239.1", "received-from": [ "IP4", "127.0.0.1" ], "from-tag": "74e83539b18d115a", "command": "offer" }
... "call-id": "d07e00c875f64161", "via-branch": "z9hG4bKe298.e03e6127f4e4ac3a82a67f02c6453239.0", "received-from": [ "IP4", "127.0.0.1" ], "from-tag": "74e83539b18d115a", "command": "offer" }
followed by delete:
Dec 3 12:20:44 lohi rtpengine[10306]: [d07e00c875f64161] Dump for 'delete' from 127.0.0.1:51239: { "call-id": "d07e00c875f64161", "via-branch": "z9hG4bKe298.e03e6127f4e4ac3a82a67f02c6453239.1", "received-from": [ "IP4", "127.0.0.1" ], "from-tag": "74e83539b18d115a", "command": "delete" }
results in this:
Dec 3 12:20:44 lohi rtpengine[10306]: [d07e00c875f64161] Scheduling deletion of call branch '' (via-branch 'z9hG4bKe298.e03e6127f4e4ac3a82a67f02c6453239.1') in 30 seconds
i.e., only one branch will be deleted.
Looks like I in parallel forking cases need to use the extra param to set the branch value.
Thanks,
-- Juha
On 03.12.2015 12:30, Juha Heinanen wrote:
Richard Fuchs writes:
I have a prospective fix in a separate branch: https://github.com/sipwise/rtpengine/tree/rfuchs/delete-branch
Can you please test it to see if it works for your use case, then I'll merge into master.
Richard,
I had chance to test this branch and it worked as I expected. With earlier version these two offers:
Hello Juha,
If you have the scenario in place and some time for it, can you please try [1] for rtpengine module, kamailio side?
It is related to the pull-request for rtpengine hash table to keep the nodes selected for a call. We are not able to test it since we are not using rtpengine's via-branch feature. We are running it for ~ two weeks from now, in the test system, and didn't spotted problems so far (without via-branch).
Thank you, 1&1 Team
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" }
then i decline one branch and rtpengine-delete is called (using via-branch=1):
Dec 4 01:24:02 lohi rtpengine[10306]: [138d9b5516741c30] Received command 'delete' from 127.0.0.1:52496 Dec 4 01:24:02 lohi rtpengine[10306]: [138d9b5516741c30] Dump for 'delete' from 127.0.0.1:52496: { "call-id": "138d9b5516741c30", "via-branch": "z9hG4bKe8998a18295855da", "received-from": [ "IP4", "192.98.102.10" ], "from-tag": "b5b2ffd6a2205b13", "command": "delete" } Dec 4 01:24:02 lohi rtpengine[10306]: [138d9b5516741c30] Scheduling deletion of call branch '' (via-branch 'z9hG4bKe8998a18295855da') in 30 seconds
30 secs later i get to syslog:
Dec 4 01:24:32 lohi rtpengine[10306]: [138d9b5516741c30] Call branch '' (via-branch 'z9hG4bKe8998a18295855da') deleted
then 10 seconds later i answer the second branch and call rtpengine-answer using via-branch=2:
Dec 4 01:24:42 lohi rtpengine[10306]: [138d9b5516741c30] Received command 'answer' from 127.0.0.1:44490 Dec 4 01:24:42 lohi rtpengine[10306]: [138d9b5516741c30] Dump for 'answer' from 127.0.0.1:44490: { "sdp": "v=0#015#012o=- 1362734666 2118038312 IN IP4 10.0.2.15#015#012s=-#015#012c=IN IP4 10.0.2.15#015#012t=0 0#015#012a=tool:baresip 0.4.15#015#012m=audio 10986 RTP/AVP 96 97 0 8 101#015#012b=AS:128#015#012a=rtpmap:96 opus/48000/2#015#012a=fmtp:96 stereo=1;sprop-stereo=1;maxaveragebitrate=28000#015#012a=rtpmap:97 speex/8000#015#012a=fmtp:97 mode="3";vbr=off;cng=on#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101 0-15#015#012a=sendrecv#015#012a=label:1#015#012a=rtcp-rsize#015#012a=ssrc:49929059 cname: ... Dec 4 01:24:42 lohi rtpengine[10306]: [138d9b5516741c30] ... sip:jh@test.tutpro.com#015#012a=rtcp-mux#015#012a=ptime:20#015#012", "ICE": "force", "replace": [ "session-connection", "origin" ], "call-id": "138d9b5516741c30", "via-branch": "z9hG4bKe8998a18295855da", "received-from": [ "IP4", "192.98.102.10" ], "from-tag": "b5b2ffd6a2205b13", "to-tag": "14f16e4bb432882f", "command": "answer" }
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?
-- juha
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
Richard Fuchs writes:
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).
That was my question: how it is possible that the call worked even when the answer came AFTER 30 seconds when the call was already deleted.
But it is not important since as you pointed out, via-branch needs to be setup properly.
-- Juha
On 12/04/2015 07:19 PM, Juha Heinanen wrote:
Richard Fuchs writes:
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).
That was my question: how it is possible that the call worked even when the answer came AFTER 30 seconds when the call was already deleted.
From your log, it was only 10 seconds between
Dec 4 01:24:32 lohi rtpengine[10306]: [138d9b5516741c30] Call branch '' (via-branch 'z9hG4bKe8998a18295855da') deleted
and
Dec 4 01:24:42 lohi rtpengine[10306]: [138d9b5516741c30] Received command 'answer' from 127.0.0.1:44490
Cheers
-
Juha Heinanen -
Richard Fuchs -
smititelu