I have found very interesting call examples in my Asterisk 22.214.171.124. The whole case is based on CDRs mismatch between me and my customer, who sends calls to me. I’ve billed much more minutes than my customer and because of that we have a dispute. Some calls simply don’t figure as answered in the customer’s billing. Now I have got some traces of what is really happening, found in messages log and SIP pcap:
(>>> means direction “to me”, <<< “from me”)
2015-05-26 14:45:23.485346 >>> Invite
2015-05-26 14:45:23.486611 <<< Trying
2015-05-26 14:45:46.383521 <<< OK
2015-05-26 14:45:46.419709 >>> Cancel
2015-05-26 14:45:46.419879 >>> ACK
2015-05-26 14:45:46.419905 <<< OK
[May 26 14:46:47] NOTICE chan_sip.c: Disconnecting call ‘SIP/xxx-015a10f1’ for lack of RTP activity in 61 seconds
Do I correctly understand, that the customer sends Cancel after my OK (probably hasn’t received and interpretted my OK before sending it?), what causes that my Asterisk understands this call as answered (+60 sec RTP timeout as in sip.conf: rtptimeout=60), while his device “thinks” this call is cancelled?
How to resolve this dispute? Whose system is right? I can shorten RTP timeout, but it wouldn’t prevent this scenario from occuring. Is this an Asterisk issue, or SIP issue itself? Is there any SIP reference which describes, how a device should behave in such SIP time-coincidence? Shouldn’t my Asterisk disconnect the call after receiving Cancel? Of course I would like to resolve the dispute on my favor, but I’m not sure if this Asterisk behaviour is correct and SIP-theory-compatible…
Could anyone help?
I’ve found an interesting sentence in SIP RFC (tools.ietf.org/html/rfc3261#page-53):
“CANCEL has no effect on a request to which a UAS has already given a final response.”
Does this mean, that ignoring Cancel received after OK (which is a “final response” to Invite?) is the correct behaviour?