Re: [reSIProcate] CANCEL and Early Media

["Nilay Tripathi" <nilay.linux@xxxxxxxxx>]

Hi,

Thanks for the fix Scott :)

Just wanted to put the scenario in UAC's perspective.

- Getting a 487 from UAS is expected after a CANCEL is expected, and as a fact of matter, our UAS is sending 487 only.

The problem comes when the proxy converts it into some other 4xx
message for any reason (this is exactly what is happening in my case),
we only rely on the timer to fire and finish off the dialog.

So the point here is that we should handle any 4xx response message in
this state. Handling Race Condition, as mentioned by Byron, is another
solid point.

Regards,
Nilay

On 7/19/07, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:

I've added onInviteFailure and on491Invite to the case statement.  Thanks Nilay.

 

Scott

 

From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Nilay Tripathi
Sent: Thursday, July 19, 2007 10:25 AM
To: resiprocate-devel
Subject: [reSIProcate] CANCEL and Early Media

 

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.

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.

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

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