< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index | Next in Thread > |
Stuff inline...
Hi, Scenario: Our DUM is UAC ! 1. UAC makes a call to UAS with SDP Offer. 2. UAS responds SDP Answer in rel. 1xx. UAS starts Early media. 3. UAC is able to play the early media.4. UAC disconnects the call - sends CANCEL. State is transitioned to "UAC_Cancelled"Now, 200 OK (CANCEL) is received and is discarded at DialogUsageManager::processResponse(). When UAS sends a 487, it reaches ClientInviteSession::dispatchCancelled() and the dialog gets destroyed.Prob 1: If any other 4xx message comes (apart from 422, 487), the event would be "OnInviteFailure", which is not catered in dispatchCancelled and, therefore, onTerminated callback is not called to apprise user of call disconnect. This will only happen once the Cancelled timer fires and until then (32 sec) the media streams keep on playing.For that "OnInviteFailure" should also be added.
So, the UAS is sending something other than a 487 when it got a CANCEL? This isn't exactly correct, but I can see race-conditions happening where UAC sends CANCEL and UAS sends something other than 487 before CANCEL arrives at their end. We really ought to just take whatever response we get. So I agree that we should put OnInviteFailure in that switch statement.
Query 1: I could not understand how the ACK is going in this case. It is certainly not triggered by the DUM and is done by stack. Appreciate any inputs on this as well.ACK/failure is handled by the transaction state machine down in the stack. TUs only need to worry about ACK/2xx.
Query 2: We are just ignoring 200 OK (CANCEL) in dum. Since ACK is anyway going to be sent from Stack, why don't we finish the dialog on receiving 200 OK (CANCEL).
CANCEL/200 tells you nothing other than "Ok, I got your CANCEL". Keep in mind that CANCEL is _advisory_. The UAS could ignore it completely. We only know what action the UAS took when we get an INVITE response.
Similar ideas are already floating on the mailing list, perhaps this can be taken as a use-case for that argument :)Thanks 'n' Regards, Nilay _______________________________________________ resiprocate-devel mailing list resiprocate-devel@xxxxxxxxxxxxxxxxxxxx https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
Attachment:
smime.p7s
Description: S/MIME cryptographic signature