SIP signalling coincidence causes billing mismatch

Asterisk Asterisk Support
1

Hi all,

I have found very interesting call examples in my Asterisk 1.8.20.0. 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[17437] 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? :smile:

//EDIT:
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?

2

The critical point is that they have sent ACK, which means they have accepted your OK to the original INVITE and they have not subsequently sent a BYE to terminate it, so their call to you is up. (Even if they hadn’t sent ACK, the UAS would simply repeat the OK until they did.

Asterisk appears to have handled this sequence correctly.

Also note that they are not necessarily at fault in sending the CANCEL because it takes finite time for the messages to go across the network, and there is only 36ms between the messages. The other side may well not have seen the OK at the time it sent the CANCEL. Where it is at fault is that it doesn’t follow up with a BYE.

I seem to remember that some earlier versions of Asterisk had problems in handling CANCEL collisions and failed to convert them into BYEs, so they may be running out of date Asterisk software. In all cases they are running buggy SIP UAC software.

3

Thank you for your reply, David.

Yes, I’m aware that they probably haven’t seen my OK before sending CANCEL and the time of network delivery causes this, but I wasn’t sure how my Asterisk should handle this. Now I know, that I should suggest it is their fault because they don’t BYE a call in these situations, and quote the mentioned sentence from RFC. Thanks!