This topic contains 7 replies, has 0 voices, and was last updated by Anonymous 3 years ago.
- January 30, 2016 at 6:29 pm #699
My 1.4 pyfreebilling for all LCR routes returns NORMAL_CLEARING for all calls while providers have different disconnect causes like NORMAL_TEMPORARY_FAILURE and NORMAL_CIRCUIT_CONGESTION!!!
it makes my customers mad!!!!!
does anybody knows a solution for that?
- January 30, 2016 at 7:48 pm #776
Hi. It dépends on cause really sens by customer. Did you catch thé sip hangup cause ?
- January 31, 2016 at 9:09 pm #777
this is a sample CDR record which one provider returned CALL_REJECTED, second one retunrned NORMAL_TEMPORARY_FAILURE and lastly we send NORMAL_CLEARING to the client !!!
Jan. 31, 2016, 12:11 p.m. Xtel Afghanistan Etisalat Mobile 93783081138 00:00 NORMAL_CLEARING (None) 0.00000 0.03000 9378 NCLI DTSW
Jan. 31, 2016, 12:11 p.m. Xtel Afghanistan Etisalat Mobile 93783081138 00:00 NORMAL_TEMPORARY_FAILURE Ali 0.02990 0.03000 9378 NCLI DTSW
Jan. 31, 2016, 12:11 p.m. Xtel Afghanistan Etisalat Mobile 93783081138 00:00 CALL_REJECTED Rain 0.02990 0.03000 9378 NCLI DTSW
- February 1, 2016 at 8:08 am #781
We see in CDR the different leg CDRs. As you know, a call is composed with 2 legs (at minimum), leag A corresponding to the caller ans leg B to the callee.
We see in your example that you try to connect the leg A with 2 differents GW. You get different failure causes for each one. The failure cause from the legA is NORMAL_CLEARING. That’s normal, as the hangup cause comes from legB.
Also, you will get more information when you click on CDR : in Call detailed infos, you get the real SIP cause. It is here, in the 1st CDR that you will find the sip cause send to the caller.
Then, the hangup cause send by PyFreeBilling to the caller part, could be different that the error receive by the legB.
- February 1, 2016 at 6:44 pm #784
As you see none of b-legs returned NORMAL_CLEARING, one of them was CALL_REJECTED and the other one was NORMAL_TEMPORARY_FAILURE !!!!
- February 4, 2016 at 8:29 am #790
The 1st CDR in the leg A and the others one the leg B.
So, did you capture the sip answer to the customer ?
Also, did you have a look to the Called Details infos of the 1st CDR (leg A) ?
- February 5, 2016 at 5:31 pm #791
caller ID num: 182510544722
q.850: 16 hangup disposition: send_refuse SIP hangup cause:
sip user agent:
customer IP address: X.X.X.X
b leg UUID: channel name: sofia/internal/182510544722@X.X.X.X Country:
- February 6, 2016 at 7:52 am #792
You see that PyFreeBilling sent a refuse message to pour customer. With the sip capture (or activité siptrace in fs cli), you will get the exact SIP message sent
You must be logged in to reply to this topic.
- Click to share on Twitter (Opens in new window)
- Click to share on Facebook (Opens in new window)
- Click to share on Pinterest (Opens in new window)
- Click to share on Tumblr (Opens in new window)
- Click to share on WhatsApp (Opens in new window)
- Click to share on Reddit (Opens in new window)
- Click to share on Telegram (Opens in new window)