Re: [MEDIACTRL] FW: Race condition between msc-ivr dialogstart and SIP ACK

"WORLEY, Dale R (Dale)" <> Mon, 05 July 2010 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75ACA28C0E1 for <>; Mon, 5 Jul 2010 11:11:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.19
X-Spam-Level: *
X-Spam-Status: No, score=1.19 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_50=0.001, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0bGWOB8ID2ry for <>; Mon, 5 Jul 2010 11:11:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7F73428C0DC for <>; Mon, 5 Jul 2010 11:11:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,541,1272859200"; d="scan'208";a="23761342"
Received: from unknown (HELO ([]) by with ESMTP; 05 Jul 2010 14:11:04 -0400
X-IronPort-AV: E=Sophos;i="4.53,541,1272859200"; d="scan'208";a="488852975"
Received: from (HELO ([]) by with ESMTP; 05 Jul 2010 14:11:04 -0400
Received: from ([]) by ([2002:870b:3414::870b:3414]) with mapi; Mon, 5 Jul 2010 14:11:03 -0400
From: "WORLEY, Dale R (Dale)" <>
To: Stéphane Bastien <>, "" <>
Date: Mon, 05 Jul 2010 14:11:03 -0400
Thread-Topic: [MEDIACTRL] FW: Race condition between msc-ivr dialogstart and SIP ACK
Thread-Index: AcsFWnNu3CC53NWeSL6Q+YEz94hOQAA2eBxQAy4AraACYA9uOA==
Message-ID: <>
References: <21866C7FE177A4449B9136B5B24B1B1303702B9F38@EXMBXCLUS01.citservers.local>
In-Reply-To: <21866C7FE177A4449B9136B5B24B1B1303702B9F38@EXMBXCLUS01.citservers.local>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MEDIACTRL] FW: Race condition between msc-ivr dialogstart and SIP ACK
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Jul 2010 18:11:13 -0000

From: [] On Behalf Of Stéphane Bastien

5.       Application Server sends a SIP ACK with the answer SDP to the Media Server

6.       Application Server transmits over the control channel an msc-ivr <dialogstart> with a connectionid of the media session established in step 5

The problem is what happens if the SIP ACK transmitted in step 5 gets lost in the network? One of the retransmissions of the SIP ACK may eventually reach the Media Server, but will be received later than the dialogstart from step 6. Yet, the Media Server can’t execute the dialogstart until the SIP ACK is received, otherwise the user gets media clipping.

I'm currently thinking of handling  this scenario by waiting for a few seconds in step 6 if the SIP ACK is missing, and execute <dialogstart> as soon as the SIP ACK arrives. If the SIP ACK does not arrive, the MS returns the msc-ivr status code 412 "Media stream not available". (Could we create an error code for this specific scenario to make it easier to detect by the AS?) An alternate approach would be for the AS to subscribe to the state of a connectionid, and the Media Server would send a "Media Stream Established" notification when receiving the SIP ACK in step 5.

(Speaking as an individual.)

I'm not familiar with this particular application, but in general, it's easier to implement a protocol if actions are taken on when indications are received rather than based on timeouts.  So it would seem more robust and easier to code if we required the MS to send an indication to the AS that it had received the answer SDP, and the AS would then send the <dialogstart>.  But it appears that the mechanism for doing that is having the AS specifically subscribe to the connectionid (carried in the SDP?) and then wait for a notification, which adds several more steps.

Is there a way to do this which works the same way regardless of which end sends the offer SDP?