Re: [OpenSIPS-Users] CDR Accounting not working from this provider

Bogdan-Andrei Iancu Tue, 31 May 2011 07:41:00 -0700

Hi James,

The dialog module does not "see" the BYE, so the dialog is counted asstill ongoing so no CDR is generated.

Now, about the BYE - by default dialog module exclusively uses a cookie(the "did" param in the RR/Route header) to do the matching.

As you can see in the trace, because you do RR for re-INVITE (youshouldn't, but normally useless), the cookie is lost - and the devicesending the BYE is brain-dead enough to "refresh" its route set duringthe reINVITE - even if the RFC says clear that the route set is learnedonly when the dialog is established.

Bottom line, because of the combination of un-nesessary RR and brokenUA, the cookie gets lost and it does not appear in BYE, so it does notmatch.

A fast fix you can try is to set the matching mode of dialog mode toFALLBACK from "did" based matching to SIP-wise matching, so the dialogmatching will match the BYE against the dialog even if the cookie ismissing.


Regards,
Bogdan

On 04/23/2011 07:54 AM, jam...@vicidial.com wrote:

I have a new provider that I am evaluating and the built-in CDRfunctionality of the acc module is not working for them. I have testedwith a second provider and it works fine. I can only assume thatsomething somewhere in the SIP dialog is causing it to loose track ofit. Here is the SIP dialog:


interface: any
filter: (ip) and ( port 5060 )
#
U 2011/04/22 23:06:09.857893 208.38.149.190:5060 -> 208.38.149.182:5060
INVITE sip:18633939336@208.38.149.182;cpd=on SIP/2.0
Via: SIP/2.0/UDP 208.38.149.190:5060;branch=z9hG4bK745a7a33;rport
From: "James P." <sip:8633939330@208.38.149.190>;tag=as791c05d3
To: <sip:18633939336@208.38.149.182;cpd=on>
Contact: <sip:8633939330@208.38.149.190>
Call-ID: 38b57ce271946530476aea3909a8de2b@208.38.149.190
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70

Remote-Party-ID: "James P."<sip:8633939330@208.38.149.190>;privacy=off;screen=no

Date: Sat, 23 Apr 2011 03:12:17 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 264

v=0
o=root 23976 23976 IN IP4 208.38.149.190
s=session
c=IN IP4 208.38.149.190
t=0 0
m=audio 13872 RTP/AVP 18 0 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

#
U 2011/04/22 23:06:09.858211 208.38.149.182:5060 -> 208.38.149.190:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 208.38.149.190:5060;branch=z9hG4bK745a7a33;rport=5060
From: "James P." <sip:8633939330@208.38.149.190>;tag=as791c05d3
To: <sip:18633939336@208.38.149.182;cpd=on>
Call-ID: 38b57ce271946530476aea3909a8de2b@208.38.149.190
CSeq: 102 INVITE
Content-Length: 0


#
U 2011/04/22 23:06:09.859762 208.38.149.182:5060 -> 69.30.55.34:5060
INVITE sip:18633939336@69.30.55.34;cpd=on SIP/2.0
Record-Route: <sip:208.38.149.182;lr;ftag=as791c05d3;did=4c6.e8830ff>
Via: SIP/2.0/UDP 208.38.149.182;branch=z9hG4bK4956.b46847f.0