Subject: RE: [Sipping] New version of the early media draft

From: "Mark Watson" <[email-masked]>
Date: Fri, 7 Mar 2003 10:02:36 -0000

Gonzalo,

The 200 OK vs RTP packet race condition is a smaller problem than correctly
deciding whether to play in-band media or local ringing. It doesn't
necessarily justify media detection at the MG anyway (or rather. the MG
taking 'autonomous' action on the basis of media detecion, which is the
problematic part) .

I don't think that cutting through the actual media just on the basis of
receipt of a media packet would be an acceptable solution in some (common)
business models anyway - they will want to wait for the 200 OK before
cutting through media. If that results in speech clipping then your RTT is
probably too long for acceptable speech quality anyway.

Also, as a general layering principle, I think it is bad to attach semantics
to the presence/absence of RTP packets - the expected state of the media
stream should be completely known to the endpoints based on the SIP/SDP
negotiations. This surely makes the system more robust and assists debugging
because it allows be to detect an error case where I am expecting to receive
media but do not.

I am confused by the resistance to solving this problem in the
straightforward way. The existance of in-band media seems a perfectly
reasonable thing to want to signal at the SIP layer. People seem quite happy
to give the 183 message this semantic, for the case where the call state is
unknown - why is it such a big deal to convey the *same information* at the
SIP layer for the case where the call state is known to be alerting ?? All I
want to do is atomically signal the equivalent of 180 *plus* 183.

...Mark 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 07 March 2003 09:27
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: Peterson, Jon; 'Ejzak, Richard P (Richard)'; sipping; Audet,
> Francois [SC100:4K02:EXCH]
> Subject: Re: [Sipping] New version of the early media draft
> 
> 
> Mark,
> 
> the text says that such a flag would not solve that issue, because you
> have to implement media detection *anyway* for covering other 
> scenarios
> (motivational paragraph at the bottom).
> 
> > I still think this problem remains unsolved.
> 
> The point is that such a flag would not solve it either.
> 
> Gonzalo
> 
> Mark Watson wrote:
> > 
> > Gonzalo,
> > 
> > Your text does not recognise the desire to avoid reading 
> semantics in
> > to the arrival of RTP packets, to cope with the MGC/MG scenario.
> > 
> > I still think this problem remains unsolved.
> > 
> > ...Mark
> > 
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:[email-masked]]
> > > Sent: 07 March 2003 08:48
> > > To: Peterson, Jon
> > > Cc: 'Ejzak, Richard P (Richard)'; Watson, Mark
> > > [MOP:EP10:EXCH]; sipping;
> > > Audet, Francois [SC100:4K02:EXCH]
> > > Subject: Re: [Sipping] New version of the early media draft
> > >
> > >
> > > Folks,
> > >
> > > I agree with Jon that we should not encourage people to 
> send in-band
> > 
> > > ringing tones, but I also agree with Mark that this issue has
> > > re-surfaced a number of times already. The message we want to get
> > > through is that adding a SIP flag for resolving that issue
> > > offers little
> > > or no value.
> > >
> > > I am willing, if people agree, to add some text saying 
> why it is not
> > a
> > > good idea to add a SIP-layer flag to 180 responses indicating
> > > that media
> > > is coming.
> > >
> > > What about a section along these lines:?
> > >
> > > 2.2.1 Problems with SIP-layer Indications in 180 Responses
> > >
> > > As stated above, it is not an easy task for a UAC that receives a
> > 180
> > > (Ringing) response to decide whether it should generate local
> > ringback
> > > or it will be receiving early media. At first sight, it may seem
> > that
> > > adding a "there is media coming" indication to 180 (Ringing)
> > responses
> > > would facilitate the task of UACs. Upon reception of a 
> 180 (Ringing)
> > 
> > > response with such an indication, the UAC would not generate local
> > > ringback. However, such an indication would offer little 
> or no gain.
> > 
> > >
> > > The only scenario where such an indication would be applicable is
> > when
> > > the UAS sends a 180 (Ringing) response and starts sending early
> > media
> > > right away. If the UAS intended to send early media at a 
> later time,
> > 
> > > instead of right away, a sensible local policy for the 
> UAC could be
> > to
> > > generate local ringback in the meantime. Therefore, the
> > > "there is media
> > > coming" indication would be useless.
> > >
> > > Assuming, then, that the UAS sends the 180 (Ringing) response and
> > the
> > > first media packets in parallel towards the UAC, we have a race
> > > condition. If the media packets arrive at the UAC before the 180
> > > (Ringing) response, the "there is media coming" 
> indication will not
> > > provide any further information to the UAC.
> > >
> > > The only situation where the UAC could benefit from that 
> indication
> > is
> > > when the 180 (Ringing) response arrives before the first
> > > media packets.
> > > The UAC could avoid generating local ringback for an instant
> > > before the
> > > first media packets arrive. However, the same result can be
> > > achieved in
> > > a much simpler way (without protocol extensions) by just 
> having UACs
> > 
> > > always delay the generation of local ringback for a short 
> period of
> > > time. The UAC can, for instance, generate a short beep upon
> > > reception of
> > > the 180 (Ringing) response (this is already done by some
> > > circuit-switched mobile terminals) and one second later start
> > > generating
> > > local ringback if no media have been received during that period.
> > >
> > > \motivation{Note that adding such an indication does not keep
> > > UACs from
> > > implementing media arrival detection either, since they have to
> > > implement it anyway to cover other scenarios, like the race
> > condition
> > > between the 200 OK for the INVITE and the first regular media
> > > packets).}
> > >
> > >
> > > Opinions?
> > >
> > > Gonzalo
> > >
> 
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  [email-masked]
> Finland                   http://www.hut.fi/~gonzalo
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Mar 2003 12:26:44 +0200

Mark,

> The 200 OK vs RTP packet race condition is a smaller problem than
> correctly deciding whether to play in-band media or local ringing. It
> doesn't necessarily justify media detection at the MG anyway (or
> rather. the MG taking 'autonomous' action on the basis of media
> detecion, which is the problematic part) .
> 
> I don't think that cutting through the actual media just on the basis
> of receipt of a media packet would be an acceptable solution in some
> (common) business models anyway - they will want to wait for the 200
> OK before cutting through media. If that results in speech clipping
> then your RTT is probably too long for acceptable speech quality
> anyway.

The RTT for the media packets has *nothing* to do with the RTT for SIP
signalling. If I introduce ten proxies providing services around the
world for a call to another user in my ethernet, I will have a very long
SIP RTT, but a very short media RTT.

Therefore, your MG needs to implement media detection anyway to avoid
media clipping (200 OK-RTP race condition).

> Also, as a general layering principle, I think it is bad to attach
> semantics to the presence/absence of RTP packets - the expected state
> of the media stream should be completely known to the endpoints based
> on the SIP/SDP negotiations. This surely makes the system more robust
> and assists debugging because it allows be to detect an error case
> where I am expecting to receive media but do not.

The state of the media toold is given by the SDP. The media tools for a
sendrecv stream are "on". Some time ago, I proposed to introduce more
states into SDP (not only direction, but also intention of the sender),
and we finally concluded that it was a bad idea because of media
clipping and race conditions.

> straightforward way.

I still have not heard a single proposal that solves this. If there is a
good solution, I will be more than happy to document it, but as I stated
before, having a SIP flag does not solve the problem.

> The existance of in-band media seems a perfectly
> reasonable thing to want to signal at the SIP layer. People seem quite
> happy to give the 183 message this semantic, for the case where the
> call state is unknown - why is it such a big deal to convey the *same
> information* at the SIP layer for the case where the call state is
> known to be alerting ?? All I want to do is atomically signal the
> equivalent of 180 *plus* 183.

Well, a 183 response does not imply that there will be media. Examples
of 183 responses without early media are preconditions and encapsulated
early ACMs.

And the reason why we do not have "there is media coming" indications in
neither response is because the value of a flag like that is close to
zero, per the previous analysis.

Gonzalo
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP