#11 cancel call before ringing

closed
None
5
2010-10-23
2010-07-08
Jozek;
No

Call can be cancelled only after ringing message appears. No exception is generated. That's just a long shot, but maybe terminate() method in UAC.java is source of problem, because it distinguish between initialRequest and midDialogRequest?

Discussion

1 2 3 4 > >> (Page 1 of 4)
  • Jozek;
    Jozek;
    2010-07-08

    • assigned_to: nobody --> yohannmartineau
    • priority: 5 --> 7
     
  • Jozek;
    Jozek;
    2010-07-08

    • priority: 7 --> 5
     
  • Jozek;
    Jozek;
    2010-07-08

    I added SIP logs from PortaSIP. As you can see, there is no CANCEL Request from Peers before ringing even when I was trying.

     
  • Jozek;
    Jozek;
    2010-07-08

    I noticed difference between xlite and peers SIP log. It appears that second INVITE has different "branch" on the UAC side then all requests and responses before. In XLite log "branch" is the same through entire call.

     
  • Jozek;
    Jozek;
    2010-07-21

    In new updated version cancelling doesn't work at all. If I find anything I write it down asap.

     
  • Jozek;
    Jozek;
    2010-07-21

    I think problem lies in method getClientTransaction in TransactionManager class. At line 112 there is:

    return clientTransactions.get(getTransactionId(branchId, method));

    BranchID and method gives the String: "branchId|ACK". The problem is that clientTransactions Hashtable contains only two INVITEs and two REGISTERs. As a result return method returns null object and "preProcessCancel" method in CancelHandler throws RuntimeException at line 151 which is:
    SipResponse lastResponse = inviteClientTransaction.getLastResponse();

     
  • what do you mean by "doesn't work at all"?
    can you send me transport.log and peers.log?

    thanks

     
  • you can attach wireshark captures, but please use pcap format, I can hardly take the most of traces without complete (at least sip) network dump.

     
  • Jozek;
    Jozek;
    2010-07-21

    My mistake, cancel works fine during conversation, but not before. If I call from peers to phone I can hang up only after conversation started. I add log and captures in a while.

     
  • Jozek;
    Jozek;
    2010-07-21

    Hang up clicked after my phone started ringing

     
    Attachments
  • Jozek;
    Jozek;
    2010-07-21

    log for shark.pcap

     
    Attachments
  • Jozek;
    Jozek;
    2010-07-21

    log for shark.pcap

     
    Attachments
  • Jozek;
    Jozek;
    2010-07-21

    Logs&trace attached

     
  • Thanks for traces, I first thought it could come from the following things:
    - no content length in 180?
    - bad record-route handling? with a strange ftag parameter?
    - 401 response on INVITE which has been rarely tested IIRC? 407 response on INVITE has been tested often, but 401 rarely, but 401 and 407 are treated strictly the same way in peers.

    I wrote a small sipp test which tries to reproduce your error, it does not include challenge management, but just INVITE, 100, 180, CANCEL, 200 (CANCEL), 487 (INVITE) and ACK. And it cannot reproduce your bug. So the first two options are wrong in my suppositions. I have to test the last one. I attach my trace and sipp script.

     
  • test ok

     
  • INVITE, 100, 180, CANCEL, 200 (CANCEL), 487 (INVITE) and ACK

     
    Attachments
  • Jozek;
    Jozek;
    2010-07-21

    I'll try to take a look on trace and script today if I found a little bit of time.

    There was one time when my CANCEL request was sent but branch was different(with second INVITE it chagnes) and it wasn't passed. I noticed there is a TODO in handleAck method of InviteHandler class. I guess recognizing reINVITE would cause not changing branch?
    But it only happened once. Normally my CANCEL request is not seen by PortaBilling.

     
  • there are several TODOs in handleAck in InviteHandler, but they are all media-related.

    so you mean there were:

    - INVITE branchid1
    - 401
    - ACK
    - INVITE branchid2
    - 180
    - CANCEL branchid2

    if this is what you meant, it's a normal behavior.

    If you have:
    - INVITE branchid1
    - 401
    - ACK
    - INVITE branchid2
    - 180
    - CANCEL branchid3

    Then, there's an error in peers.

     
  • Jozek;
    Jozek;
    2010-07-21

    No, there are only tow branchIds. One branchId idea came to me after I saw XLite sip-log from porta, where was only one branchId from a XLite side. However if you say secont INVITE may have different branchid - i don't argue.

    In short, my sip-log says what you wrote down:
    - INVITE branchid1
    - 401
    - ACK
    - INVITE branchid2
    - 180

    but CANCEL doesn't appear in PortaBilling. It seems peers just don't send it, likely because of the exception I mentioned earlier.

     
  • okay, so you can't see any CANCEL on portasip.
    you mean there's somewhere a runtime exception which is caught nowhere in peers code?
    sorry, but there's something I can't understand regarding your comment:

    "BranchID and method gives the String: "branchId|ACK". The problem is that
    clientTransactions Hashtable contains only two INVITEs and two REGISTERs.
    As a result return method returns null object and "preProcessCancel" method
    in CancelHandler throws RuntimeException at line 151 which is:
    SipResponse lastResponse = inviteClientTransaction.getLastResponse();"

    How can ACK method be used in this part of the code whereas no ACK has been sent by peers at this time?
    You meant this was an error on CANCEL sending, wasn't it?

     
  • sorry, I think I got it, that's right, when you hangup after 100 trying reception (or even before), but before 180, the call is considered as active, and should be either automatically terminated within 64 * T1, i.e. 32s (rfc3261 §9.1) or transaction should be removed and call should not succeed.

     
  • Jozek;
    Jozek;
    2010-07-22

    Yes, however actual version has a problem with cancelling before 200 OK, not only before 180. Sequence:
    - 200OK
    - ACK
    - BYE
    performs geat, but before 200OK it's impossible to break call, likely because of the RuntimeException or the source of it - creating inviteClientTransaction in preProcessCancel of CancelHandler class.

     
  • actually, I think a clarification is necessary:

    when you send an INVITE in SIP, you can have several scenarios:
    1. no response or provisional responses with no tag in header To. In this case, a timer is started at INVITE sending. If you hung up and no response with a tag in header To has been received, the invite client transaction is simply dropped, and if a response with a tag in header To arrives after timer triggered, this response is ignored, retransmissions will be sent by UAS, but as no ACK will be received by UAS, the transaction will be considered as failed and the dialog will be destroyed. If a response with a tag in header To is received before timer triggers, two cases.
    First case: this response is a provisional response, then a CANCEL will be sent by UAC. When you send a CANCEL you are not sure you will receive a 487, you can also receive a 200. If you receive a 200, you have to terminate the call with a BYE.
    Second case: this reponse is a final response, if this is a successful response (2xx), you have to terminate the call with a BYE, if this is an error response, you have nothing to do, the call has already been terminated.
    2. at least one provisional response with a tag in header To, in this case, you have to send a CANCEL, as previously mentioned. The same way, you may have to send a BYE if you receive a 200 OK.
    3. one successful response, in this case you have to terminate the call with a BYE to terminate the call
    4. one error reponse, in this case, the call has already been terminated on UAS side, you don't need to do anything.

    The bug I was talking about in the previous comment was in scenario #1. Apparently, you mean there is also an exception in scenario #2. I think it would really help me if you could send me a stack trace corresponding to this scenario. Sensu stricto in RFC3261 terms, there can be no "cancelling" before reception of a provisionnal response with tag in header To.

     
  • Jozek;
    Jozek;
    2010-07-22

    wireshark trace

     
1 2 3 4 > >> (Page 1 of 4)