#386 On decline/hangup force quit the UI even if Server doesn't acknowledge the end of the call

[Anonymous]

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.

[Anonymous]

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).

[Anonymous]

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

[Anonymous]

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.

[Anonymous]

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

[Anonymous]

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

[Anonymous]

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.

[Anonymous]

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