[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sr-dev
Subject:    [OpenSER-Devel] [ openser-Bugs-1801898 ] route-set bug in presence
From:       wiquan () employees ! org (Will Quan)
Date:       2007-09-29 23:18:00
Message-ID: 46FEC227.6010403 () employees ! org
[Download RAW message or body]

Juha,
My response was only to shed some light into why the R-R headers are
allowed in mid-call requests, not an attempt to sway opinions of whether
or not it is a good idea. The ietf obviously thought it was a good idea,
but your not required to do it.

So given your examples your 100% right, but please also consider this:
Is it possible that the UAS is a SIP call-server supervising a media
gateway peripheral via H.248 or similar protocol?
Is it possible that media is streaming through the MG peripheral while
the call-server is failing over to a secondary?
Perhaps call-servers can initiate audits of the MG (e.g H.248 context
audit).
I don't know the answers, but I suspect the primary benefit might be
that active calls are not dropped, while a mid-call request (eg.
hold/retrieve) could re-create the dialog.

I don't know of any specifications requiring this kind of behavior, or
what you described.

regards,
--will

Juha Heinanen wrote:
> Will Quan writes:
>
>  > The R-R headers are added to new request to give a chance to crashed
>  > end-points to
>  > re-create state from a mid-dialog request such as re-INVITE to
>  > refresh the call. This is clearer from Section 16.6: Step 4.
>
> i don't know any UA that is able to re-create a dialog after crash.
> also, many UAs will delete an invite dialog if (due to crash) there is no
> media from the other UA rather than start sending re-invites to
> it.  
>
> where is it specified that an UA should start sending re-invites to the
> other end if media stops flowing?  how long should an UA do so?
>
> if nowhere, it is sometimes a good idea to use one's brains rather than
> believing everything an ietf document says.
>
> -- juha
>   


[prev in list] [next in list] [prev in thread] [next in thread]