8 Feb
2007
8 Feb
'07
12:56 p.m.
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
12 Feb
12 Feb
3:18 p.m.
New subject: [Users] Re: MEDIAPROXY - Cannot detect inactive rtp sessions, any other BYE fix method?
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(a)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
6496
days inactive
6500
days old
1 comments
1 participants
participants (1)
-
Dan-Cristian Bogos