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?
I'm glad I can help. Logs added. There's also CANCEL in scenario 3 this time. I don't know why previously there was no CANCEL, cause in SIPLog from Porta there is no difference at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I know what is the source of our problems. When CallFrame is created, the field "sipRequest" is filled with the request with branchID of first INVITE. Then method hangUp() invokes hangUpClicked(sipRequest) method with sipRequest containing first branchID.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes, sorry I should have told you, I've already identified it was coming from here. The fact is that fixing this requires a real state machine on sip core level, which is not implemented yet. And a new state machine means at least 4 to 5 classes more, so I need more time to fix it cleanly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sorry for delay, I udpated the code, could you retry? Finally, I tried to fix it without any state machine. As I already have a state machine on gui level, I don't want to add one that would just manage this specific issue. I reproduced the bug with a light modification in code. I removed the delay before new invite sending after challenge. I tried the same scenario after the fix and it worked, so I hope it will work for you too.
Thank you
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have to say it works really nice now. However there's still a little problem. When you click Hangup right after clicking Call physical phone starts ring and immediately call is cancelled. Looking into Porta's SIPLogs gives the answer what's going on:
Cancel is sent after second 100trying with branchID of first INVITE. After 180 Ringing received by peers CANCEL is sending with proper branchID of second INVITE.
Cancelling after first 180Ringing works great, so we're close I guess.
I may add logs if you wish.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hello, I added a trace in InviteHandler, could you retry and send peers.log and transport.log again?
You should see something like "cancel after prov response: sipRequest..."
thank you
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes, actually, I think the provisionnal response is notified to InviteHandler with the wrong transaction, I still don't know why, but it's the reason why I added the log message. In this message, I display the response and the request. The request is retrieved from the transaction, and I think this transaction is the old one (the one of the first invite). Nevertheless, I think the response is the right one.
could you give me traces to confirm this guess?
thank you
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess you ment Wireshark trace. It's added.
Yes, there is some problem with transactions, but still debugger didn't help me to find why it behaves like that.
thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi, I commited a fix on UAC.java, could you update this class and retry?
thanks
I wrote another sipp script to reproduce the bug, I reproduced it, modified UAC.java and retried sipp script and it was okay (cancel was sent with branch id of the invite with xxxAuthorization header).
Thank you
If it works for you I close the bug.
Thank you
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
newScenario2
newScenario3
I'm glad I can help. Logs added. There's also CANCEL in scenario 3 this time. I don't know why previously there was no CANCEL, cause in SIPLog from Porta there is no difference at all.
Hi
I think I know what is the source of our problems. When CallFrame is created, the field "sipRequest" is filled with the request with branchID of first INVITE. Then method hangUp() invokes hangUpClicked(sipRequest) method with sipRequest containing first branchID.
yes, sorry I should have told you, I've already identified it was coming from here. The fact is that fixing this requires a real state machine on sip core level, which is not implemented yet. And a new state machine means at least 4 to 5 classes more, so I need more time to fix it cleanly.
No need to sorry, I just assumed it may help. Good luck!
hi,
sorry for delay, I udpated the code, could you retry? Finally, I tried to fix it without any state machine. As I already have a state machine on gui level, I don't want to add one that would just manage this specific issue. I reproduced the bug with a light modification in code. I removed the delay before new invite sending after challenge. I tried the same scenario after the fix and it worked, so I hope it will work for you too.
Thank you
Hi yohann,
I have to say it works really nice now. However there's still a little problem. When you click Hangup right after clicking Call physical phone starts ring and immediately call is cancelled. Looking into Porta's SIPLogs gives the answer what's going on:
Cancel is sent after second 100trying with branchID of first INVITE. After 180 Ringing received by peers CANCEL is sending with proper branchID of second INVITE.
Cancelling after first 180Ringing works great, so we're close I guess.
I may add logs if you wish.
Thanks
It seems that somehow 180RINGING sets the proper branchID for CANCEL. At least that's what I see in SIPLog from Porta.
could you give me traces for this issue? (both transport.log and peers.log)
thank you
Sure, logs are added.
hello, I added a trace in InviteHandler, could you retry and send peers.log and transport.log again?
You should see something like "cancel after prov response: sipRequest..."
thank you
Yes, you're right - "cancel after prov..." appears in peers.log. Is that the sign that peers is getting know what's going on?
yes, actually, I think the provisionnal response is notified to InviteHandler with the wrong transaction, I still don't know why, but it's the reason why I added the log message. In this message, I display the response and the request. The request is retrieved from the transaction, and I think this transaction is the old one (the one of the first invite). Nevertheless, I think the response is the right one.
could you give me traces to confirm this guess?
thank you
I guess you ment Wireshark trace. It's added.
Yes, there is some problem with transactions, but still debugger didn't help me to find why it behaves like that.
thanks
no, I meant peers.log with the specific log message I added. I need to know which sipRequest and which sipResponse are used in invite handler.
thank you
newest log
OK, sorry for mix-up. I added peers.log.
could you also provide transport.log so that I can check date and time of message reception?
thank you
Yes, I forgot about it, my bad. Transport log is added.
hi, I commited a fix on UAC.java, could you update this class and retry?
thanks
I wrote another sipp script to reproduce the bug, I reproduced it, modified UAC.java and retried sipp script and it was okay (cancel was sent with branch id of the invite with xxxAuthorization header).
Thank you
If it works for you I close the bug.
Thank you