On decline/hangup force quit the UI even if Server doesn't acknowledge the...
Brought to you by:
krunalhire
Originally created by: mccor...@gmail.com
Originally owned by: r3gis...@gmail.com
What steps will reproduce the problem?
1. Make a call
2. Do not answer the call at the other end
3. Attempt to hang up on CSipSimple initiating side
What is the expected output? What do you see instead?
The UI should hang up and go back to the main view. Instead the other end stops ringing successfully, but the UI indicates it is still trying to ring on the CSipSimple side. See the attached log for the errors produced.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
Seems that there is something wrong with the sip server:
sip_endpoint.c Error processing packet from 203.25.26.98:5060: Missing required header(s) (PJSIP_EMISSINGHDR) Via [code 171050]:
A missing header.
Did you find a solution to this problem? Maybe something to check on the server side. (Maybe something that doesn't respect RFC.... if not maybe it should be reported to pjsip guys).
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: mccor...@gmail.com
Apparently this is due to our upstream SIP-to-PSTN provider. For calls that exit the SIP network they are not responding with the correct headers on hangup.
It seems to me though that the UI shouldn't hang or do the wrong thing just because the server is behaving badly. Surely it would be a better behaviour in the case of a buggy server to close the socket, force the call to hang up and return the UI to the main screen? What do you think?
http://en.wikipedia.org/wiki/Robustness_principle
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
Yes could be a good idea, but not so easy to implement :
pjsip consider the call finished only if properly finished in SIP control flow or if timeout.
If think there is some really good reason for doing it like it in the pjsip stack.
However, indeed, maybe the UI part could make things before getting feedback from server.
But would be really complicated to develop and could introduce a lot of instability. While here CSipSimple has no intelligence and rely completely on pjsip mechanism, I always resent introducing intelligence inside the UI cause it's not the job of the UI to manage this kind of problematic.
But well, we can try to say hang-up & decline directly finish the in call activity and see if we get some regression feedback.
Or maybe some better idea could be to tune more finely the timeout.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
(No comment was entered for this change.)
Summary: On decline/hangup force quit the UI even if Server doesn't acknowledge the end of the call
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low Component-Logic
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: privus...@gmail.com
Hmmm,
I also consider this to be important from a usability perspective.
I've tried many SIP clients, and all seem to hangup the call immediately (or at least in the UI) as soon as hangup is pressed, regardless of the server's response and/or proper timeouts.
With CSipSimple using [r1915] this doesn't happen. ie. sometimes when one presses hangup in CSip, the call will continue anyway ignoring repeated hangup attempts until it finally hangs up and returns to the main UI (timeout must eventually have been reached I presume).
Now although this may be the proper SIP implementation, it causes lots of user complaints. Many users tell me the software is broken becuase it takes so long to hangup and they don't want to use it again.
So, my question is, if you don't want to change this behaviour to force the call to hangup (or at least have the UI return to the main menu after pressing hangup), where in the source code is this function implemented? I wouldn't mind taking a look myself and changing it to my liking whenever I find the time.
Thanks r3gis
Related
Commit: [r1915]
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: mig...@aboratec.com
Hi there,
I have the same problem with the UI thread while hanging out. I've realized mostly of the cases happens when your are connected via 3g. ¿Any solutions to this problem?
Thanks.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: csecsi.u...@gmail.com
Have the same issue, quite often, probably when there is a network change or drop in the hangup phase. But it is really annoying, I agree.
The simplest solution would be a "force hangup" option in the call dropdown menu, which would at least hang up in the UI, the background is up to you :)
Merci