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

Stéphane Bastien <stephane@broadsoft.com> Wed, 23 June 2010 15:59 UTC

Return-Path: <stephane@broadsoft.com>
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 1ECB03A6880 for <mediactrl@core3.amsl.com>; Wed, 23 Jun 2010 08:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.302
X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id LFiVE9Q5wAdl for <mediactrl@core3.amsl.com>; Wed, 23 Jun 2010 08:59:42 -0700 (PDT)
Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net []) by core3.amsl.com (Postfix) with ESMTP id 85ABA3A682E for <mediactrl@ietf.org>; Wed, 23 Jun 2010 08:59:42 -0700 (PDT)
Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:]) by casumhub01.citservers.local ([]) with mapi; Wed, 23 Jun 2010 08:59:49 -0700
From: Stéphane Bastien <stephane@broadsoft.com>
To: "mediactrl@ietf.org" <mediactrl@ietf.org>
Date: Wed, 23 Jun 2010 08:59:44 -0700
Thread-Topic: Race condition between msc-ivr dialogstart and SIP ACK
Thread-Index: AcsFWnNu3CC53NWeSL6Q+YEz94hOQAA2eBxQAy4AraA=
Message-ID: <21866C7FE177A4449B9136B5B24B1B1303702B9F38@EXMBXCLUS01.citservers.local>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
acceptlanguage: fr-FR, en-US
Content-Type: multipart/mixed; boundary="_004_21866C7FE177A4449B9136B5B24B1B1303702B9F38EXMBXCLUS01ci_"
MIME-Version: 1.0
Subject: [MEDIACTRL] FW: Race condition between msc-ivr dialogstart and SIP ACK
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jun 2010 15:59:53 -0000


Since I did not get any reply, I suggest that we create a new response status code 414 "SIP media dialog not confirmed" that is returned when a dialogstart is received but the Media Server is missing the SIP ACK for the associated connectionid. The application server can then wait a little and retry sending the dialogstart, hoping that SIP retransmissions will have finally delivered the SIP ACK to the Media Server.


From: mediactrl-bounces@ietf.org [mailto:mediactrl-bounces@ietf.org] On Behalf Of Stéphane Bastien
Sent: 7 juin 2010 07:29
To: mediactrl@ietf.org
Subject: [MEDIACTRL] Race condition between msc-ivr dialogstart and SIP ACK


In a scenario where we establish a media session using SIP INVITE without an SDP, we are facing a race condition with the msc-ivr dialogstart command. The scenario is described below:

1.       A control channel is already established between an Application Server and a Media Server

2.       Application Server sends SIP INVITE without an SDP to Media Server to establish the media session

3.       Media Server responds with a SIP 200 OK with an offer SDP

4.       Application Server transmits offer SDP to remote endpoint; gets an answer SDP in return

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.

Has anyone else encountered this problem? What was your solution?