Opened 14 years ago
Last modified 6 years ago
#1049 new enhancement
PJSUA-LIB should report disconnection event immediately after pjsua_call_hangup() is called — at Version 4
Reported by: | bennylp | Owned by: | bennylp |
---|---|---|---|
Priority: | normal | Milestone: | release-2.10 |
Component: | pjsua-lib | Version: | trunk |
Keywords: | Cc: | ||
Backport to 1.x milestone: | Backported: | no |
Description (last modified by bennylp)
There are several scenarios in which call DISCONNECTED state will only be reported later, if at all, after pjsua_call_hangup() is issued:
- when INVITE is not responded with any responses yet (not even provisional responses), which in this case, PJSIP will continue retransmitting the request until either a response is received (and if it's not a final response, CANCEL then will be issued), or retransmission times out 32 seconds after call is initiated.
- when BYE is issued against peer which doesn't exist; in this case, the DISCONNECTED state will be issued after the BYE transaction times out, 32 seconds after it is issued
- when BYE is answered with failure final response; in this case, most likely call will stay as is. Note that 408 and 481 response would cause call to be terminated though.
~when 200/OK for CANCEL is received, but the final response for the INVITE transaction never arrives; in this case, call will remain as is indefinitely (!)~ (done in #503)- when ACK is not received yet for 200/OK, UAS is not able to send BYE (see #1712). The stack ideally should send the BYE automatically once ACK is received
In all cases above, it is desirable to have the application receives the DISCONNECTED event immediately and let PJSUA-LIB handle the call under the hood. Several scenarios that must be handled by PJSUA-LIB include:
- sending BYE if call isn't disconnected after CANCEL is issued, possibly using a timer:
- it is possible that the CANCEL request and 200/OK to INVITE had crossed each other in the wire; in this case, the call will get CONNECTED and the CANCEL will be rejected with 481 (please check this in the spec)
~peer may have been malfunctioning, not disconnecting the call even after sending 200/OK response to CANCEL. We may need to have a timer for this.~ (done in #503)
- retry sending the BYE if previous ones fail and call remains connected. If this keeps happening (the BYE request gets rejected), we'll probably need to hard-terminate the call, that is to forcefully terminate the call without relying for the BYE to succeed.
- when ACK is not received yet for 200/OK, UAS is not able to send BYE (see #1712). The stack ideally should send the BYE automatically once ACK is received
Change History (4)
comment:1 Changed 14 years ago by bennylp
- Milestone changed from Known-Issues-and-Ideas to release-2.x
comment:2 Changed 10 years ago by bennylp
- Backported unset
- Description modified (diff)
comment:3 Changed 10 years ago by bennylp
- Description modified (diff)
comment:4 Changed 10 years ago by bennylp
- Description modified (diff)
Note: See
TracTickets for help on using
tickets.