5 Jul
2006
5 Jul
'06
7:31 p.m.
Hi,
I am having a problem with OpenSER and certain types of CPEs. The problem is
that the calls get established and the parties can talk, however after a
very short period the call gets disconnected. Any guidelines how I could
troubleshoot this?
PS: Is there anyway to see the calls disconnect cause on OpenSER? I am
currently running OpenSER with radius.
Thanks in advance,
Hamid
5 Jul
5 Jul
7:34 p.m.
On Wednesday 05 July 2006 12:31, Hamid Ali Asgari wrote:
Are the calls from one UA to another, or from a UA to a gateway? I know for
instance that Asterisk has problems with G729b silence detection and will
drop calls because it thinks the call has dropped. Perhaps other equipment or
carriers has this problem too.
---Mike
Hi,
I am having a problem with OpenSER and certain types of CPEs. The problem
is that the calls get established and the parties can talk, however after a
very short period the call gets disconnected. Any guidelines how I could
troubleshoot this?
PS: Is there anyway to see the calls disconnect cause on OpenSER? I am
currently running OpenSER with radius.
Thanks in advance,
Hamid
7:44 p.m.
The calls are between two UAs.
The problem is that with a certain type of UA (type A), the calls are ok if
the calls are between two type A UAs and don't get disconnected. I can talk
as long as I want.
But if I try calling from that UA (type A) to Windows messenger, the call
gets disconnects after less than a minute. In the 1 minute I can talk (so I
assume it's not a CODEC problem, correct me if I am wrong)
I have also tried with a UA and a Cisco gateway. On the Cisco debugs I see
Disconnet cause code 102 (Session-End-Callback ) which I don't think would
be the case. There is no callback config on the gateway or the UA.
I guess the UA is tearing down the call for some reasn I don't know.
Any clues?
Hamid
-----Original Message-----
From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On Behalf
Of Mike Williams
Sent: Wednesday, July 05, 2006 8:04 PM
To: users(a)openser.org
Subject: Re: [Users] Disconnect Cause on OpenSER
On Wednesday 05 July 2006 12:31, Hamid Ali Asgari wrote:
Are the calls from one UA to another, or from a UA to a gateway? I know for
instance that Asterisk has problems with G729b silence detection and will
drop calls because it thinks the call has dropped. Perhaps other equipment
or
carriers has this problem too.
---Mike
Hi,
I am having a problem with OpenSER and certain types of CPEs. The problem
is that the calls get established and the parties can talk, however after
a
very short period the call gets disconnected. Any
guidelines how I could
troubleshoot this?
PS: Is there anyway to see the calls disconnect cause on OpenSER? I am
currently running OpenSER with radius.
Thanks in advance,
Hamid
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
8:07 p.m.
Hi,
it might be a signalling problem. Most of the UA drops the calls if they
do not get the ACK for 200 OK.
check on the network if this is the case.
regards,
bogdan
Hamid Ali Asgari wrote:
The calls are between two UAs.
The problem is that with a certain type of UA (type A), the calls are ok if
the calls are between two type A UAs and don't get disconnected. I can talk
as long as I want.
But if I try calling from that UA (type A) to Windows messenger, the call
gets disconnects after less than a minute. In the 1 minute I can talk (so I
assume it's not a CODEC problem, correct me if I am wrong)
I have also tried with a UA and a Cisco gateway. On the Cisco debugs I see
Disconnet cause code 102 (Session-End-Callback ) which I don't think would
be the case. There is no callback config on the gateway or the UA.
I guess the UA is tearing down the call for some reasn I don't know.
Any clues?
Hamid
-----Original Message-----
From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On Behalf
Of Mike Williams
Sent: Wednesday, July 05, 2006 8:04 PM
To: users(a)openser.org
Subject: Re: [Users] Disconnect Cause on OpenSER
On Wednesday 05 July 2006 12:31, Hamid Ali Asgari wrote:
Are the calls from one UA to another, or from a UA to a gateway? I know for
instance that Asterisk has problems with G729b silence detection and will
drop calls because it thinks the call has dropped. Perhaps other equipment
or
carriers has this problem too.
---Mike
Hi,
I am having a problem with OpenSER and certain types of CPEs. The problem
is that the calls get established and the parties can talk, however after
a
very short period the call gets disconnected. Any
guidelines how I could
troubleshoot this?
PS: Is there anyway to see the calls disconnect cause on OpenSER? I am
currently running OpenSER with radius.
Thanks in advance,
Hamid
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6 Jul
6 Jul
8:45 a.m.
I also remember (triggered by the 1 minute thing) that some gateways
expect to see RTCP signalling along with the RTP. If they do not then
they consider the call dead and clear it out.
On Wed, 2006-07-05 at 20:07 +0300, Bogdan-Andrei Iancu wrote:
Hi,
it might be a signalling problem. Most of the UA drops the calls if they
do not get the ACK for 200 OK.
check on the network if this is the case.
regards,
bogdan
Hamid Ali Asgari wrote:
>The calls are between two UAs.
>The problem is that with a certain type of UA (type A), the calls are ok if
>the calls are between two type A UAs and don't get disconnected. I can talk
>as long as I want.
>
>But if I try calling from that UA (type A) to Windows messenger, the call
>gets disconnects after less than a minute. In the 1 minute I can talk (so I
>assume it's not a CODEC problem, correct me if I am wrong)
>
>I have also tried with a UA and a Cisco gateway. On the Cisco debugs I see
>Disconnet cause code 102 (Session-End-Callback ) which I don't think would
>be the case. There is no callback config on the gateway or the UA.
>
>I guess the UA is tearing down the call for some reasn I don't know.
>
>Any clues?
>Hamid
8 Jul
8 Jul
4:50 p.m.
I don't know if this has to do with the problem or not, but I made a test
call and I saw in the debugs from openser:
1(2819) DBG: trans=0xb6077e98, callback type 128, id
0 entered
1(2819) ACC: call missed: method=INVITE, i-uri=sip:0098146@shatel.ir,
o-uri=sip:0098146@shatel.ir, call_id=f81b4d8cf177452a81b025328dcf1a8c,
from="101(a)shatel.ir"
<sip:101@shatel.ir>;tag=7f769f5701f54635860ff36d287f7001;epid=9f3b191481,
code=408 Request Timeout
The call got established and I talked for a while. In the radius log I have
some records like this what I have pasted bellow.
2 Questions:
--------------
1) Many times I don't have start records for a call, there are some records
with "Acct-Status-Type = Failed" and a STOP with no start. Can anyone
clarify this please?
2)Why are these records with "Acct-Status-Type = Failed" generated
durinng the call? Does this have anything to do with the 1 minute disconnect
problem.
Thanks in advance,
Hamid
----------------------------------------------------------------------------
--
Wed Jul 5 19:41:42 2006
Acct-Status-Type = Start
Service-Type = Sip-Session
Sip-Response-Code = 200
Sip-Method = 4
User-Name = "102(a)shatel.ir"
Calling-Station-Id = "sip:102@shatel.ir"
Called-Station-Id = "sip:101@shatel.ir"
Sip-Translated-Request-URI =
"sip:85.15.7.18;ftag=analog-sip16159;lr"
Acct-Session-Id = "3650(a)192.168.11.102"
Sip-To-Tag = "b6e86c1ced224eb49d21214eb6b057ca"
Sip-From-Tag = "analog-sip16159"
Sip-Cseq = "101"
Attr-108 = 0x3139322e3136382e31312e313032
Attr-109 = 0x35303630
NAS-Port = 5060
Acct-Delay-Time = 0
NAS-IP-Address = 127.0.0.1
Client-IP-Address = 127.0.0.1
Acct-Unique-Session-Id = "aff25d9f102f0597"
Timestamp = 1152112302
Wed Jul 5 19:41:42 2006
Acct-Status-Type = Failed
Service-Type = Sip-Session
Sip-Response-Code = 404
Sip-Method = 4
User-Name = "102(a)shatel.ir"
Calling-Station-Id = "sip:102@shatel.ir"
Called-Station-Id = "sip:101@shatel.ir"
Sip-Translated-Request-URI =
"sip:85.15.7.18;ftag=analog-sip16159;lr"
Acct-Session-Id = "3650(a)192.168.11.102"
Sip-To-Tag = "b6e86c1ced224eb49d21214eb6b057ca"
Sip-From-Tag = "analog-sip16159"
Sip-Cseq = "101"
Attr-108 = 0x38352e31352e372e3138
Attr-109 = 0x35303630
NAS-Port = 5060
Acct-Delay-Time = 0
NAS-IP-Address = 127.0.0.1
Client-IP-Address = 127.0.0.1
Acct-Unique-Session-Id = "aff25d9f102f0597"
Timestamp = 1152112302
[ remaining FAILURE records ommited ]
Wed Jul 5 19:42:14 2006
Acct-Status-Type = Failed
Service-Type = Sip-Session
Sip-Response-Code = 404
Sip-Method = 4
User-Name = "102(a)shatel.ir"
Calling-Station-Id = "sip:102@shatel.ir"
Called-Station-Id = "sip:101@shatel.ir"
Sip-Translated-Request-URI =
"sip:85.15.7.18;ftag=analog-sip16159;lr"
Acct-Session-Id = "3650(a)192.168.11.102"
Sip-To-Tag = "b6e86c1ced224eb49d21214eb6b057ca"
Sip-From-Tag = "analog-sip16159"
Sip-Cseq = "101"
Attr-108 = 0x38352e31352e372e3138
Attr-109 = 0x35303630
NAS-Port = 5060
Acct-Delay-Time = 0
NAS-IP-Address = 127.0.0.1
Client-IP-Address = 127.0.0.1
Acct-Unique-Session-Id = "aff25d9f102f0597"
Timestamp = 1152112334
Wed Jul 5 19:42:46 2006
Acct-Status-Type = Stop
Service-Type = Sip-Session
Sip-Response-Code = 200
Sip-Method = 8
User-Name = "101(a)shatel.ir"
Calling-Station-Id = "sip:101@shatel.ir"
Called-Station-Id = "sip:102@shatel.ir"
Sip-Translated-Request-URI = "sip:102@192.168.11.102:5060"
Acct-Session-Id = "3650(a)192.168.11.102"
Sip-To-Tag = "analog-sip16159"
Sip-From-Tag = "b6e86c1ced224eb49d21214eb6b057ca"
Sip-Cseq = "1"
Attr-108 = 0x3139322e3136382e31312e313130
Attr-109 = 0x33363636
NAS-Port = 5060
Acct-Delay-Time = 0
NAS-IP-Address = 127.0.0.1
Client-IP-Address = 127.0.0.1
Acct-Unique-Session-Id = "a92d70dd0564dfba"
Timestamp = 1152112366
14 Jul
14 Jul
4:41 p.m.
Hi,
quite difficult to say what is going on without a network trace of the
call from the server machine.
regards,
bogdan
Hamid Ali Asgari wrote:
I don't know if this has to do with the problem or
not, but I made a test
call and I saw in the debugs from openser:
1(2819) DBG: trans=0xb6077e98, callback type 128,
id 0 entered
1(2819) ACC: call missed: method=INVITE, i-uri=sip:0098146@shatel.ir,
o-uri=sip:0098146@shatel.ir, call_id=f81b4d8cf177452a81b025328dcf1a8c,
from="101(a)shatel.ir"
<sip:101@shatel.ir>;tag=7f769f5701f54635860ff36d287f7001;epid=9f3b191481,
code=408 Request Timeout
The call got established and I talked for a while. In the radius log I have
some records like this what I have pasted bellow.
2 Questions:
--------------
1) Many times I don't have start records for a call, there are some records
with "Acct-Status-Type = Failed" and a STOP with no start. Can anyone
clarify this please?
2)Why are these records with "Acct-Status-Type = Failed" generated
durinng the call? Does this have anything to do with the 1 minute disconnect
problem.
Thanks in advance,
Hamid
----------------------------------------------------------------------------
--
Wed Jul 5 19:41:42 2006
Acct-Status-Type = Start
Service-Type = Sip-Session
Sip-Response-Code = 200
Sip-Method = 4
User-Name = "102(a)shatel.ir"
Calling-Station-Id = "sip:102@shatel.ir"
Called-Station-Id = "sip:101@shatel.ir"
Sip-Translated-Request-URI =
"sip:85.15.7.18;ftag=analog-sip16159;lr"
Acct-Session-Id = "3650(a)192.168.11.102"
Sip-To-Tag = "b6e86c1ced224eb49d21214eb6b057ca"
Sip-From-Tag = "analog-sip16159"
Sip-Cseq = "101"
Attr-108 = 0x3139322e3136382e31312e313032
Attr-109 = 0x35303630
NAS-Port = 5060
Acct-Delay-Time = 0
NAS-IP-Address = 127.0.0.1
Client-IP-Address = 127.0.0.1
Acct-Unique-Session-Id = "aff25d9f102f0597"
Timestamp = 1152112302
Wed Jul 5 19:41:42 2006
Acct-Status-Type = Failed
Service-Type = Sip-Session
Sip-Response-Code = 404
Sip-Method = 4
User-Name = "102(a)shatel.ir"
Calling-Station-Id = "sip:102@shatel.ir"
Called-Station-Id = "sip:101@shatel.ir"
Sip-Translated-Request-URI =
"sip:85.15.7.18;ftag=analog-sip16159;lr"
Acct-Session-Id = "3650(a)192.168.11.102"
Sip-To-Tag = "b6e86c1ced224eb49d21214eb6b057ca"
Sip-From-Tag = "analog-sip16159"
Sip-Cseq = "101"
Attr-108 = 0x38352e31352e372e3138
Attr-109 = 0x35303630
NAS-Port = 5060
Acct-Delay-Time = 0
NAS-IP-Address = 127.0.0.1
Client-IP-Address = 127.0.0.1
Acct-Unique-Session-Id = "aff25d9f102f0597"
Timestamp = 1152112302
[ remaining FAILURE records ommited ]
Wed Jul 5 19:42:14 2006
Acct-Status-Type = Failed
Service-Type = Sip-Session
Sip-Response-Code = 404
Sip-Method = 4
User-Name = "102(a)shatel.ir"
Calling-Station-Id = "sip:102@shatel.ir"
Called-Station-Id = "sip:101@shatel.ir"
Sip-Translated-Request-URI =
"sip:85.15.7.18;ftag=analog-sip16159;lr"
Acct-Session-Id = "3650(a)192.168.11.102"
Sip-To-Tag = "b6e86c1ced224eb49d21214eb6b057ca"
Sip-From-Tag = "analog-sip16159"
Sip-Cseq = "101"
Attr-108 = 0x38352e31352e372e3138
Attr-109 = 0x35303630
NAS-Port = 5060
Acct-Delay-Time = 0
NAS-IP-Address = 127.0.0.1
Client-IP-Address = 127.0.0.1
Acct-Unique-Session-Id = "aff25d9f102f0597"
Timestamp = 1152112334
Wed Jul 5 19:42:46 2006
Acct-Status-Type = Stop
Service-Type = Sip-Session
Sip-Response-Code = 200
Sip-Method = 8
User-Name = "101(a)shatel.ir"
Calling-Station-Id = "sip:101@shatel.ir"
Called-Station-Id = "sip:102@shatel.ir"
Sip-Translated-Request-URI = "sip:102@192.168.11.102:5060"
Acct-Session-Id = "3650(a)192.168.11.102"
Sip-To-Tag = "analog-sip16159"
Sip-From-Tag = "b6e86c1ced224eb49d21214eb6b057ca"
Sip-Cseq = "1"
Attr-108 = 0x3139322e3136382e31312e313130
Attr-109 = 0x33363636
NAS-Port = 5060
Acct-Delay-Time = 0
NAS-IP-Address = 127.0.0.1
Client-IP-Address = 127.0.0.1
Acct-Unique-Session-Id = "a92d70dd0564dfba"
Timestamp = 1152112366
6707
days inactive
6716
days old
6 comments
4 participants
participants (4)
-
Bogdan-Andrei Iancu -
Hamid Ali Asgari -
Mike Williams -
Peter Childs