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

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

> 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 13:08:07 +0200

Mark,

If I understood your mail correctly, you acknowledge that when race
conditions are possible, a "there is media coming" does not solve
anything. But you believe that in environments where you are sure that
no race conditions will occur, such a flag would be useful.

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.

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

Gonzalo

Mark Watson wrote:
> 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
_______________________________________________
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