Bob wrote: > > Arjun wrote: > > > The MOH uses the OPTIONs as a keepalive mechanism, to > make sure the > > > dialog is still active. What's the interval between the > > OPTIONs? The > > > default I believe is 5mins. > > > > The traces we were looking at had three OPTIONs messages > back-to-back. Given their frequency and what Arjun is > saying, it does not sound like the OPTION messages we saw > were the MOH 'keep alive' messages.
I didn't notice initially either, but they were 5 minutes apart, and the first was 5 minutes after the MOH INVITE. They're also in the MOH dialog. BTW, this is the trace: http://track.sipfoundry.org/secure/attachment/17898/5dd1870e-d761efbb-7b 9706bc.xml (attached to XTRN-419.) > > Just to confirm, this is done to clean up dangling MOH dialogs? > > > > The reason I ask is that the XTRN-419 problem is that the > Polycom does > > not send BYE when taking the call off hold, and therefore > leaves the > > MOH dangling. > > > > If sipXpark cleans up these dialogs promptly, then the impact of > > XTRN-419 is much less severe. > > There is another dimension to the problem which goes beyond > the inefficient use of resources. Basically, when a MOH > session is left dangling, the phone that was involved in that > MOH continues to be hammered with RTP packets. If that phone > takes part in a new call before the dangling MOH is cleaned > up then that phone will be subjected to two RTP streams (the > dangling MOH stream and the legitimate one from the far-end) > and in the case of Polycom, because of the way it re-uses the > same RTP port across media sessions, it will receive two > different RTP streams on its media port which will confuse it > and will result in silence being played out. Ah yes, that is quite severe. Also, sipXpark continues to send OPTIONS on this dialog, I suppose because the Polycom did not terminae it. The Polycom is happily returning OK, and so it would seem that the dangling dialog is not actually being cleaned up after all. -Paul [email protected] _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
