[Home]

Summary:ASTERISK-16230: calls show some seconds on my cdrs - calls show minutes on my carrier's cdrs!!
Reporter:argeorge (argeorge)Labels:
Date Opened:2010-06-09 00:57:16Date Closed:2010-06-09 10:38:46
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have huge problem,i use asterisk with a2billing
but is not problem with billing since asteriskcdrdb also has same thing on cdrs.

I had somebody subscribing on my website and sending calls to different countries special services. from cdrs i see short calls on my system 1-5 seconds.
the provider online cdrs report 10 minutes,20 minutes or more.
My provider says that this happened again to some of their customers they say "your customer found a way to trick asterisk"
they say once the call is sent they cancel and after they send another call with same call-id and. on sip debug from his site he sees that after 10 minutes my server sends OK for re-invite...
Im loosing money and i dont know if is a bug,my provider or anything else i need your help,and if possible a security fix
directrtsetup=yes
canreinvite=yes
those are globally enabled
thanks
Comments:By: Tilghman Lesher (tilghman) 2010-06-09 01:12:32

Thank you for taking the time to report this bug and helping to make Asterisk better.

Unfortunately, we cannot work on this bug because your description did not include enough information.

You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines.

We would be grateful if you would then provide a more complete description of the problem.

At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf).

Thanks!
By: argeorge (argeorge) 2010-06-09 04:37:08

the sip trace from provider:

*i replaced fields

2010/06/08 23:43:50.753 INF: [CID=0xd80f07b7] >>>
SIP/2.0 200 OK Method(INVITE) DST: <my server ip>:5060:UDP
SRC=<customer ip>:5061 enc=0 bytes=910
2010/06/08 23:43:50.773 INF: [CID=0xd80f07b7] <<< ACK
sip:<prefix>447589000428@<customer ip>:5060 SIP/2.0 Method(ACK) SRC:
<my server ip>:5060:UDP enc=0 bytes=736
2010/06/08 23:54:51.749 INF: [CID=0xd80f07b7] <<< INVITE
sip:<customer's username>@<customer ip> SIP/2.0 Method(INVITE) SRC:
<provider ip>:5060:UDP enc=0 bytes=807
2010/06/08 23:54:51.750 INF: [CID=0xd80f07b7] >>> SIP/2.0 100 Trying
Method(INVITE) DST: <provider ip>:5060:UDP SRC=<customer ip>:5061 enc=0
bytes=465
2010/06/08 23:54:51.753 INF: [CID=0xd80f07b7] >>> INVITE
sip:<customer's username>@<my server ip> SIP/2.0 Method(INVITE) DST:
<my server ip>:5060:UDP SRC: <customer ip>:5060 enc=0 bytes=866
2010/06/08 23:54:51.754 INF: [CID=0xd80f07b7] <<< SIP/2.0 100 Giving a
try Method(INVITE) SRC: <my server ip>:5060:UDP enc=0 bytes=433
2010/06/08 23:54:51.777 INF: [CID=0xd80f07b7] <<< SIP/2.0 200 OK
Method(INVITE) SRC: <my server ip>:5060:UDP enc=0 bytes=933
2010/06/08 23:54:51.779 INF: [CID=0xd80f07b7] >>> ACK
sip:<customer's username>@<my server ip> SIP/2.0 Method(ACK) DST:
<my server ip>:5060:UDP SRC: <customer ip>:5060 enc=0 bytes=505
2010/06/08 23:54:51.780 INF: [CID=0xd80f07b7] >>> SIP/2.0 200 OK
Method(INVITE) DST: <provider ip>:5060:UDP SRC=<customer ip>:5061 enc=0
bytes=956
2010/06/08 23:54:51.783 INF: [CID=0xd80f07b7] <<< ACK
sip:<customer's username>@<customer ip>:5060 SIP/2.0 Method(ACK) SRC:
<provider ip>:5060:UDP enc=0 bytes=517
By: argeorge (argeorge) 2010-06-09 04:39:13

extension context is

[company_name]
exten => _X.,1,DeadAGI(a2billing.php|1)
exten => _X.,n,Hangup
By: argeorge (argeorge) 2010-06-09 04:42:26

[xxx]
disallow=all
host=xxx.xxx.xxx
type=peer
canreinvite=yes
allow=g729
allow=ulaw
allow=g723
codec_priority=peer
context=from-trunk-sip-xxx

privider configuration
By: argeorge (argeorge) 2010-06-09 04:48:37

sip conf variables:


vmexten=*97
context=from-sip-external
callerid=Unknown
notifyringing=yes
notifyhold=yes
limitonpeers=yes
tos_sip=cs3
tos_audio=ef
tos_video=af41
alwaysauthreject=yes
disallow=all
allow=ulaw
allow=alaw
allow=g729
allow=g723
directrtpsetup=yes
trustrpid=yes
sendrpid=yes
jbenable=no
minexpiry=60
allowguest=yes
defaultexpiry=120
srvlookup=yes
maxexpiry=3600
registerattempts=0
registertimeout=20
notifyhold=yes
rtptimeout=30
g726nonstandard=no
t38pt_udptl=no
videosupport=no
maxcallbitrate=384
canreinvite=yes
rtpholdtimeout=300
rtpkeepalive=0
checkmwi=10
notifyringing=yes
nat=no
externip=x.x.x.x
localnet=x.x.x.x/x.x.x.x
By: argeorge (argeorge) 2010-06-09 04:51:26

sip/friend account

[<account number>]
accountcode=<account number>
regexten=<account number>
amaflags=billing
context=<company_name>
dtmfmode=RFC2833
host=dynamic
nat=yes
qualify=yes
secret=xxxxxxxxx
type=friend
username=<account number>
allow=ulaw
allow=g729
regseconds=0
cancallforward=yes
By: argeorge (argeorge) 2010-06-09 04:52:28

* to rest country destinations and rest *normal customers i dont experience the problem, i dont know if the problem is on asterisk invite/rtp behaviour or provider's server
By: philipp2 (philipp2) 2010-06-09 05:53:51

Related to ASTERISK-15023?
By: David Woolley (davidw) 2010-06-09 06:14:21

The SIP trace you provided is not a proper Asterisk SIP debug trace.

To me it looks like the tail end of the initial call setup (the INVITE and any 1xx responses, are missing from the beginning), followed by overlapped re-invites from both ends.  The only thing that is slightly strange is that one of the re-invites is not rejected because of the collision.

The fact that it proceeds from INVITE to OK in 31ms in one direction and 24ms the other way, and that there are no 18x responses, tends to support the theory that these are normal, in dialogue, re-invites, not separate dialogues.

To prove otherwise, you would need all the SIP headers, so that one can see from and to tags, etc.

... and, in particular, the branch id.


By: klaus3000 (klaus3000) 2010-06-09 06:26:43

Can you provide more details about the CDRs, e.g. do your CDR and the CDR of the provider start at the same time? Is there another call at the (near) same happening (e.g. from the same user)?

Maybe the problem happens due to call transfers, e.g: User calls number1, User calls2 number2, User transfers number2 to number 1. In such scenarios it may happen that Asterisk writes CDRs at the time of the transfer (at least that was the case with Asterisk 1.2)
By: Paul Belanger (pabelanger) 2010-06-09 07:19:37

If you are able to reproduce the issue, please capture a debug log.  However, this seems to be a configuration issue
--
We require a complete debug log to help triage the issue.

This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue:

http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt
By: argeorge (argeorge) 2010-06-09 09:41:03

To klaus3000:
i have isolated cdrs from my provider and from my server
108 answered calls on provider cdrs
108 answered calls on my server cdrs
on my server cdrs calls show short calls of 1-5 seconds
on provider's switch it shows 10+ minutes,15+ minutes,20+mins,25+mins...

i cant reproduce it because,customer is not sending any more traffic and also i cant afford loosing more money from that
By: klaus3000 (klaus3000) 2010-06-09 09:47:05

Maybe the session kept hanging on your provider side?

did it only happen with calls form a single customer or with multiple customers?
By: argeorge (argeorge) 2010-06-09 10:11:39

Single customer
By: klaus3000 (klaus3000) 2010-06-09 10:28:25

if it does not happen anymore it is rather inpossible to find the cause of the problem :-(
By: Leif Madsen (lmadsen) 2010-06-09 10:38:45

Per davidw stating that we need the trace from Asterisk and that the dialog appears to be normal, and without the ability to reproduce the issue to capture the debug logs, there is nothing further we can do here.

If you are able to provide additional information from the Asterisk side after reproducing, then we may be able to move this forward, but at this point there is nothing further we can do here.