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 > _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
