[reSIProcate] CANCEL and Early Media

Nilay Tripathi nilay.linux at gmail.com
Thu Jul 19 12:27:22 CDT 2007


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 at icescape.com> wrote:
>
>  I've added onInviteFailure and on491Invite to the case statement.  Thanks
> Nilay.
>
>
>
> Scott
>
>
>
> *From:* resiprocate-devel-bounces at list.resiprocate.org [mailto:
> resiprocate-devel-bounces at list.resiprocate.org] *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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070719/71ace399/attachment.htm>


More information about the resiprocate-devel mailing list