27 Nov
2015
27 Nov
'15
1:39 a.m.
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
27 Nov
27 Nov
3:08 a.m.
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
3:21 a.m.
Richard Fuchs writes:
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
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?
2:42 p.m.
On 11/26/2015 09:21 PM, Juha Heinanen wrote:
Richard Fuchs writes:
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
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?
30 Nov
30 Nov
4:25 p.m.
On 11/27/2015 07:41 PM, 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.
Cheers
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.
3 Dec
3 Dec
11:30 a.m.
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
4 Dec
4 Dec
12:42 p.m.
On 03.12.2015 12:30, Juha Heinanen wrote:
Richard Fuchs writes:
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
[1] https://github.com/smititelu/kamailio/commits/master
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:
12:38 a.m.
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
3: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
5 Dec
5 Dec
1:19 a.m.
Richard Fuchs writes:
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
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).
4:40 a.m.
On 12/04/2015 07:19 PM, Juha Heinanen wrote:
Richard Fuchs writes:
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
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).
3072
days inactive
3080
days old
11 comments
3 participants
participants (3)
-
Juha Heinanen -
Richard Fuchs -
smititelu