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

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Mon, 5 Jul 2010 14:11:03 -0400

________________________________________
From: [email-masked] [mailto:[email-masked]] 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?

Dale

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Tue, 06 Jul 2010 12:27:32 +0500

Any automata which relies on time for success cases doesn't look good.
This problem is same if you use INFO/ACK (on UDP).
INFO reaches earlier as compared to ACK then INFO is generally queued (based on wait logic as described by you).

In long run I'll prefer reliable connecction to be used between MS and AS.

Regards,
Rahul
******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Monday, July 5, 2010 11:41 pm
Subject: Re: [MEDIACTRL] FW: Race condition between msc-ivr dialogstart and SIP ACK
To: Stéphane Bastien <[email-masked]>, "[email-masked]" <[email-masked]>

> From: [email-masked] [mailto:mediactrl-
> [email-masked]] On Behalf Of Stéphane Bastien
> 
> 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.
> 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.
> 
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 19 Jul 2010 17:13:34 -0400

Require TCP, TLS, or reliable SCTP only?  That is, no UDP allowed?

That might fly.  Comments from others, especially those that today do not have TCP stacks?

---

From: Stéphane Bastien <[email-masked]>
Date: Mon, 19 Jul 2010 18:35:46 -0700

As long as we have two separate channels (one for SIP, one for CFW), the race condition exists, regardless of the transport protocol.

I believe that an alternate solution is for the SIP INVITE establishing the media session to provide an identifier which informs the Media Server about which CFW channel will control the media session. Then, when the media session is confirmed (i.e., SIP ACK received), the Media Server can transmit a notification over the CFW channel (i.e., media session is ready).

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Tue, 20 Jul 2010 09:58:26 +0500

Some implementation issue.
FSM becomes complicated as two different events are required to initiate dialogstart with no ordering among them.
A more fundamental issue INVITE becomes a four way handshake. 
(Fourth event adding as extra identifier for confirming INVITE is over).

I think there are two issues here:

1. Unreliablity in protocol/mechanism. (Dialogstart will be sent after ACK deterministically)
2. Unreliability in implementation. (Control channel and UDP works on different process/threads etc in MS)

Unreliability in protocol/mechanism can only be removed by transport. In implementation it can exist.
e.g SCTP both dialogstart and ACK for a media session can be put inside same association. (IF INVITE is used with SCTP)

Regards,
Rahul

----- Original Message -----
From: Stéphane Bastien <[email-masked]>
Date: Tuesday, July 20, 2010 7:06 am
Subject: Re: [MEDIACTRL] FW: Race condition between msc-ivr dialogstart	and	SIP ACK
To: "[email-masked]" <[email-masked]>

> As long as we have two separate channels (one for SIP, one for 
> CFW), the race condition exists, regardless of the transport protocol.
> 
> I believe that an alternate solution is for the SIP INVITE 
> establishing the media session to provide an identifier which 
> informs the Media Server about which CFW channel will control the 
> media session. Then, when the media session is confirmed (i.e., 
> SIP ACK received), the Media Server can transmit a notification 
> over the CFW channel (i.e., media session is ready).
> 
> >> INFO reaches earlier as compared to ACK then INFO is generally 
> queued (based on wait logic as described by you).
> >> 
> ******************************************************************************************>> This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
> >> 
> *****************************************************************************************>> 
> >> To: Stéphane Bastien <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> >> 
> >>> 5.       Application Server sends a SIP ACK with the answer 
> SDP to 
> >>> the Media Server
> >>> 
> >>> Is there a way to do this which works the same way regardless 
> of 
> >>> which end sends the offer SDP?
> >>> 
> >>> Dale