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

2015-12-04 Thread smititelu

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

[1] https://github.com/smititelu/kamailio/commits/master

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


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

2015-12-04 Thread 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

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


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

2015-12-03 Thread Juha Heinanen
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

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


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

2015-12-03 Thread Juha Heinanen
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:j...@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

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


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

2015-11-30 Thread Richard Fuchs

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

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


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

2015-11-27 Thread Richard Fuchs

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

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


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

2015-11-27 Thread Juha Heinanen
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.

-- Juha

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


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

2015-11-26 Thread Juha Heinanen
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

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


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

2015-11-26 Thread Juha Heinanen
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

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


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

2015-11-26 Thread Richard Fuchs

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

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users