Hi Guys,
I know that this is not the support channel of mediaproxy, but just hoping that somebody from ag-projects is monitoring this list as well. I found out that, in my case, the SIP-BYE issue is still persistent even by using mediaproxy . If I will stop sending rtp through mediaproxy (eg by killing my client from task manager, or loosing the internet), mediaproxy will still find the session active, like nothing happened and therefore the bill will be inaquarate. I am using the version 1.7.2, and as read in the change log, 1.8.0 didn't change anything on this chapter. Is there any other solution or workarround available?
Thxs, Dan
Hello,
As I was adviced, hereby I am sedinding also the traces from mediaproxy for my calls. It looks like, after establishing the call, no further action is detected by mediaproxy. If I will use the "sessions.py" script provided in mediaproxy folder, I will see my session still in active status, and this can continue till ever. Anybody suggesting any other trick I can use? Are arround mediaproxy users expecting same issue?
Thxs in advance, Dan
2007-02-12_13:01:03.24883 request NjRkNzVmMzE1NzgwODcyZWNlNWRjMzhhZWQ0OTFlNWE. 87.139.12.167:60416:audio 87.139.12.167 babble.net local 205.177.185.10 remote X-Lite=20release=201006e=20stamp=2034025 info=totag:,to:00497751xxxxxx@babble.net,from:dan@babble.net,dispatcher:0000000061e5,fromtag:9a12cf3e 2007-02-12_13:01:03.24885 session NjRkNzVmMzE1NzgwODcyZWNlNWRjMzhhZWQ0OTFlNWE.: started. listening on 87.102.50.25:36232 2007-02-12_13:01:03.24886 execution time: 4.60 ms 2007-02-12_13:01:03.24887 request NjRkNzVmMzE1NzgwODcyZWNlNWRjMzhhZWQ0OTFlNWE. 87.139.12.167:60416:audio 87.139.12.167 babble.net local 205.177.185.10 remote X-Lite=20release=201006e=20stamp=2034025 info=totag:,to:00497751xxxxxx@babble.net,from:dan@babble.net,dispatcher:0000000061e5,fromtag:9a12cf3e 2007-02-12_13:01:03.24889 execution time: 0.32 ms 2007-02-12_13:01:03.24890 lookup NjRkNzVmMzE1NzgwODcyZWNlNWRjMzhhZWQ0OTFlNWE. 205.177.185.10:18598:audio 205.177.185.10 babble.net local babble.net unknown Cisco-SIPGateway/IOS-12.x info=totag:3378969C-184D,to:00497751xxxxxx@babble.net,from:dan@babble.net,fromtag:9a12cf3e 2007-02-12_13:01:03.24891 execution time: 0.50 ms 2007-02-12_13:01:03.24892 session NjRkNzVmMzE1NzgwODcyZWNlNWRjMzhhZWQ0OTFlNWE.: called signed in from 205.177.185.10:18598 (RTP) (will return to 205.177.185.10:18598) 2007-02-12_13:01:03.24897 session NjRkNzVmMzE1NzgwODcyZWNlNWRjMzhhZWQ0OTFlNWE.: caller signed in from 87.139.12.167:60417 (RTCP) (will return to 87.139.12.167:60417) 2007-02-12_13:01:03.24902 session NjRkNzVmMzE1NzgwODcyZWNlNWRjMzhhZWQ0OTFlNWE.: caller signed in from 87.139.12.167:1025 (RTP) (will return to 87.139.12.167:1025) 2007-02-12_13:01:03.24903 session NjRkNzVmMzE1NzgwODcyZWNlNWRjMzhhZWQ0OTFlNWE.: called signed in from 205.177.185.10:18599 (RTCP) (will return to 205.177.185.10:18599) 2007-02-12_13:01:03.24905 lookup NjRkNzVmMzE1NzgwODcyZWNlNWRjMzhhZWQ0OTFlNWE. 205.177.185.10:18598:audio 205.177.185.10 babble.net local babble.net unknown Cisco-SIPGateway/IOS-12.x info=totag:3378969C-184D,to:00497751xxxxxx@babble.net,from:dan@babble.net,fromtag:9a12cf3e 2007-02-12_13:01:03.24909 execution time: 0.25 ms 2007-02-12_13:01:03.24910 status 2007-02-12_13:01:03.24911 execution time: 0.21 ms 2007-02-12_13:01:03.24912 status 2007-02-12_13:01:03.24913 execution time: 0.23 ms 2007-02-12_13:01:03.24914 status 2007-02-12_13:01:03.24915 execution time: 0.24 ms 2007-02-12_13:01:03.24916 version 2007-02-12_13:01:03.24917 execution time: 0.09 ms
On 2/8/07, Dan-Cristian Bogos dan.bogos@gmail.com wrote:
Hi Guys,
I know that this is not the support channel of mediaproxy, but just hoping that somebody from ag-projects is monitoring this list as well. I found out that, in my case, the SIP-BYE issue is still persistent even by using mediaproxy . If I will stop sending rtp through mediaproxy (eg by killing my client from task manager, or loosing the internet), mediaproxy will still find the session active, like nothing happened and therefore the bill will be inaquarate. I am using the version 1.7.2, and as read in the change log, 1.8.0 didn't change anything on this chapter. Is there any other solution or workarround available?
Thxs, Dan