[OpenSER-Devel] [ openser-Bugs-1801898 ] route-set bug in presence
module
Will Quan
wiquan at employees.org
Sat Sep 29 23:22:47 CEST 2007
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
>
More information about the Devel
mailing list