Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delay in Receiving CANCEL from INVITE Transaction After Recent Updates #198

Open
moksh-samespace opened this issue Feb 24, 2025 · 4 comments

Comments

@moksh-samespace
Copy link

After updating to the latest version, I've noticed a significant delay in receiving a CANCEL message from an INVITE transaction. This was not the case with the previous version. Below is a snippet of the code where the issue is being observed:

for {
    select {
    case <-tx.Acks():
        fmt.Println("Ack received")
    case <-tx.Done():
        fmt.Println("Transaction done", tx.Err() == sip.ErrTransactionCanceled)
        // Signal transaction is done.
        // Check any errors with tx.Err() to have more info why terminated
        return
    }
}
@emiago
Copy link
Owner

emiago commented Feb 24, 2025

Hi @moksh-samespace . There is UDP termination timer. This library follows some extensions RFC.
You can check your state transitions with sip.TransactionDebug and debug logging

@moksh-samespace
Copy link
Author

Yes, I can see the debug log. However, I need to access the 'done' event immediately as I need to take action based on it. How can I achieve this?

Log:

{"level":"debug","caller":"transactionLayer","key":"z9hG4bK-524287-1---c0e4633ad76b1c5f__127.0.0.1__50502__INVITE","input":"server_input_user_1xx","state":"inviteStateProcceeding-fm","time":"2025-02-25T11:06:43+05:30","message":"Changing transaction state"}
{"level":"debug","caller":"transactionLayer","key":"z9hG4bK-524287-1---c0e4633ad76b1c5f__127.0.0.1__50502__INVITE","input":"server_input_cancel","state":"inviteStateProcceeding-fm","time":"2025-02-25T11:06:47+05:30","message":"Changing transaction state"}
{"level":"debug","caller":"transactionLayer","time":"2025-02-25T11:06:47+05:30","message":"Passing 487 on CANCEL"}
{"level":"debug","caller":"transactionLayer","key":"z9hG4bK-524287-1---c0e4633ad76b1c5f__127.0.0.1__50502__INVITE","input":"server_input_user_300_plus","state":"inviteStateProcceeding-fm","time":"2025-02-25T11:06:47+05:30","message":"Changing transaction state"}
{"level":"debug","caller":"transactionLayer","key":"z9hG4bK-524287-1---c0e4633ad76b1c5f__127.0.0.1__50502__INVITE","input":"server_input_ack","state":"inviteStateCompleted-fm","time":"2025-02-25T11:06:47+05:30","message":"Changing transaction state"}

@emiago
Copy link
Owner

emiago commented Feb 25, 2025

Cancelation is something still open thing, but essentially I see this will need some hook.
Now as some other approach, you have to check error, on every ACK from tx.Acks() or zero out that sip timer. Timer_H I think.

For better behavior, cancelation hook or something similar will be added. Had no time to look on this.
We had this in past, but it caused more issues

@moksh-samespace
Copy link
Author

I see, thanks for the update. I will work around timers for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants