[reSIProcate] CANCEL and Early Media

[Byron Campen]

	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 at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070719/fed991ed/attachment.bin>