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
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
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@openser.org [mailto:users-bounces@openser.org] On Behalf Of Mike Williams Sent: Wednesday, July 05, 2006 8:04 PM To: users@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@openser.org [mailto:users-bounces@openser.org] On Behalf Of Mike Williams Sent: Wednesday, July 05, 2006 8:04 PM To: users@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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
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@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@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@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@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@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@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@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@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@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
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@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:
- 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@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@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@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@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@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@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@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@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
-
Bogdan-Andrei Iancu -
Hamid Ali Asgari -
Mike Williams -
Peter Childs