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

From: "Mark Watson" <[email-masked]>
Date: Fri, 7 Mar 2003 11:23:03 -0000

> Mark,
> 
> If I understood your mail correctly, you acknowledge that when race
> conditions are possible, a "there is media coming" does not solve
> anything.

No, I acknowledge it doesn't solve the race conditions.

> But you believe that in environments where you are sure that
> no race conditions will occur, such a flag would be useful.
> 

No, I am saying that the solution that you have proposed is not appropriate
for a decomposed Media Gateway/Media Gateway Controller case. I acknowledge
that the race condition problem still exists in that case (e.g. at answer),
but I still think the media detection solution is not appropriate. So,
perhaps the race condition problem remains unsolved in that case, but I am
not so concerned about that problem.

> However, we do not design SIP with that type of environments in mind.
> Any SIP mechanism should work assuming that SIP-RTP race conditions
> occur.
> 

Of course not, but surely we do design SIP in a way which can work on a
gateway designed according to other IETF standards for gateways
(specifically megaco) ?

Even if you do want to assume a monolithic SIP UA, then I still think it's
valuable to pay attention to the layering in the system. I still believe
it's more robust if the media stream state is known at the signalling layer.

> Maybe you are after a P-flag to use in close environments where SIP
> signalling always beat RTP packets?
> 

Not exactly. The SIP message does not need to beat the RTP packet anyway.
There are well-established standards which imply acceptable times within
which cut-through should occur at answer, for example.

> Gonzalo
> 
> 
> 
> Mark Watson wrote:
> > 
> > > 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.
> > 
> > Yes, ok, my mistake on the RTT.
> > 
> > >
> > > Therefore, your MG needs to implement media detection anyway to
> > avoid
> > > media clipping (200 OK-RTP race condition).
> > >
> > 
> > Unless you are in an environment where you're sure the SIP 
> RTT is low
> > enough for this not to be a problem.
> > 
> > Nevertheless, it is not the race conditions and speech 
> clipping that I
> > am worried about (I'm happy to accept that this indicator does not
> > solve those problems.) In the case that the UAC is a decomposed
> > MGC/MG, the MGC needs to instruct the MG whether to play local media
> > or whether to play in-band media. The MG should not make 
> this decision
> > on its own. Early Media may well not be allowed in all cases due to
> > the call state, policy of the gateway & only the MGC has all this
> > information. The MGC needs some information at the SIP 
> layer in order
> > to make this decision.
> > 
> > Reporting media detection from the MG to MGC is, I think, 
> too kuldgy,
> > too slow & IMO puts the indication at the wrong layer. A further
> > option would be to keep the MG informed of 'what to do if 
> you receive
> > media packets', but this is not supported (to my knowledge) in the
> > MG/MGC signalling standards, is overly complex and still puts the
> > indication at the wrong layer.
> > 
> > An additional indicator in SIP/SDP in the 180 that in-band media is
> > present would provide a solution. I don't care how the indicator is
> > coded in the SIP message and we are on the SIPPING list anyway, so
> > that discussion is out of scope.
> > 
> > ...Mark
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Mar 2003 14:31:16 +0200

Mark,

OK, now I think I understand you. You want to develop a flag to be used
by systems that do not care about media clipping (they are probably in a
controlled environment without race conditions) but care about not
having to perform media detection (because they are distributed;
MGC-MG).

One of the assumption when designing SIP was that systems cared about
media clipping... I do not think we can develop general extensions at
this point in time that cause media clipping in order to resolve things
like ringback generation.

You may want to create a document that defines a P-flag and says: if you
do not care about media clipping for some reason, use this flag to have
accurate information in the SIP layer about the presence of media.

I understand what you are after, but I do not think we have a *general*
mechanism that resolves it.

Gonzalo

Mark Watson wrote:
> No, I am saying that the solution that you have proposed is not
> appropriate for a decomposed Media Gateway/Media Gateway Controller
> case. I acknowledge that the race condition problem still exists in
> that case (e.g. at answer), but I still think the media detection
> solution is not appropriate. So, perhaps the race condition problem
> remains unsolved in that case, but I am not so concerned about that
> problem.
> 
> Of course not, but surely we do design SIP in a way which can work on
> a gateway designed according to other IETF standards for gateways
> (specifically megaco) ?
> 
> Even if you do want to assume a monolithic SIP UA, then I still think
> it's valuable to pay attention to the layering in the system. I still
> believe it's more robust if the media stream state is known at the
> signalling layer.
> 
> Not exactly. The SIP message does not need to beat the RTP packet
> anyway. There are well-established standards which imply acceptable
> times within which cut-through should occur at answer, for example.
_______________________________________________
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