Subject: RE: [Sipping] Early media; philosophical discussion

From: "Mark Watson" <[email-masked]>
Date: Fri, 4 Apr 2003 14:58:20 +0100

Gonzalo,

Inline...

Gonzalo wrote:
> Hi Mark,
> 
> Mark wrote:
>  > so I guess I am now arguing more from an
>  > 'in principle' position.
> 
> Good. Given that there are no use cases, let's discuss 
> "philosophically" 
> in which layer the presence or absence of media should be signalled; 
> signalling or media level.
> 

I did not say there were no use cases. You're selectively quoting me. Nice
try though :-)

I'll admit that the use-case I described (Q.SIG/Q.931 interworking) might
not be sufficiently important on its own to motivate this indication - that
doesn't mean there are no use-cases. But I believe the principle should lead
us to expect more use-cases to be identified in future.

> The discussion could be formulated as follows:
> 
> At the signalling level (SIP/SDP), we already have the SDP direction 
> attributes, that tell the status (on/off) of the media tools. 
> When the 
> media tools are on (e.g., sendrecv stream), we do not know 
> whether there 
> really is media flowing between both ends. Should we detect 
> the presence 
> of media on the media layer (RTP) or signal it on the 
> signalling layer 
> (SIP)?
> 

Well, perhaps we *are* repeating the discussion on sendrecv/inactive. I must
say it is not entirely clear to me what it means for a stream to be in
sendrecv mode but for there to be no media being sent i.e. there is no
implementation-independent definition of what these 'media tools' are and
what it means for them to be 'on' or 'off'. We can only presume that 'on'
means that the device is in some sense 'ready' to send or receive. But what
does it mean to the UAC that the UAS is 'ready' to send media ? How is this
different for the UAC from the state where the UAS is 'not ready' to send
media ?

What is important is whether media is actually being sent - this information
is not available at the signalling layer.

> I claim that we do not need further information (in addition 
> to on/off) 
> in the signalling layer. My initial arguments are:
> 
> o When the signalling layer says that there will be media, everything 
> works fine. However, when the signalling layer says that 
> there will NOT 
> be media, it is not reliable. Since the next signalling 
> message saying 
> that media will resume may arrive later than the actual 
> (resumed) media 
> packets, either you perform media detection at the media 
> layer *anyway* 
> or have media clipping. This seems to indicate that the media 
> layer is 
> the proper place to detect presence or absence of media, 
> since half of 
> the time you end up doing it there even with a 
> signalling-layer indication.
> 

This is not an architectural argument, but a treatment of the specific issue
of media clipping. Your description makes assumptions which, conveniently,
lead to the conclusion that the indication is not needed. For example the
assumption that local policy allows media to be played indepedently of the
session state. This assumption is not fundamental to SIP - I think whether
media should be played or not at any given time is a local issue for the UA.

> o The rules of protocol design say that a protocol can be considered 
> good when you cannot get rid of anything else (KISS) as long as the 
> protocol provides the expected functionality. That is, 
> protocol design 
> consists of removing useless features rather than adding them. In our 
> case, we can get rid (by not creating it) of the flag while providing 
> the same level of functionality and requiring a very similar 
> processing 
> power and badwidth consumption. Why would we want to add 
> something that 
> does not bring any visible gain?
> 

Well, obviously, if I thought there was no gain at all I wouldn't be
advocating it. I'm not just trying to waste everyone's time.

I agree that this indication is available at the media layer in the form of
RTP packet arrival (btw, we are assuming it will be available at the media
layer in all cases, whereas SIP is supposed to be agnostic about what the
media layer, described by the SDP, is/does - I'm not saying I have an
example in which this indication is not available, but it is not
inconceivable that there could be no difference at the media layer between
"no media being sent" and "media being sent, but happens to be 'silent'" in
some sense - 'silent' could mean many things in the context of media other
than voice/audio).

All you've argued above is that 'this is available at the media layer and so
would be redundant if added to the signalling layer as well', but this is
only true with some assumptions about the communication available between
media and signalling layers and assumptions that the communication at media
and signalling layers have similar properties in terms of security,
reliability etc.

...Mark

> Cheers,
> 
> 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
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 07 Apr 2003 10:15:37 +0300

Mark,

you are commenting my arguments, but not refuting them or providing 
compelling arguments in favor of placing that indication in the SIP 
layer instead.

 > This is not an architectural argument, but a treatment of the 
specific > issue of media clipping.

I will try to re-phrase the argument so that it is clearer. I believe I 
might know what your "in-principle" concern comes from.

SIP signalling, because of its nature (loosely coupled with the media) 
cannot be used to signal things that take place in real-time in the 
media path (e.g., sudden resume of the media traffic). SIP is not 
suitable for that because you cannot be sure whether or not your 
signalling message will reach the remote end before the event in the 
media path (e.g., arrival of media) happens.

That much to argue that SIP is not the proper place for a "there is 
media coming" indication.

Now, you said that you "feel" that such an indication belong to the 
signalling plane (explicit), rather than to the media plane 
(implicit)... and I agree with you on this.

I believe that the confusion comes from the fact that when SIP is used 
to establish RTP/UDP sessions, there is only one signalling layer (i.e., 
SIP/SDP). But this is not true in general. Generally speaking, you want 
to have two layers of signalling. One is SIP/SDP. It is useful for 
things like locating the remote user, rendezvous, etc... SIP is supposed 
to provide the remote end with all the information it needs to establish 
the session.

The second signalling layer takes care of establishing the actual 
session using the information that SIP/SDP have provided. This 
signalling layer does not exist in RTP/UDP, but it does in TCP 
(three-way handshake). And if you take SCTP, for instance, you will see 
that it has much more functionality than in TCP. It deals with 
fail-over, multihoming, multistreaming, etc...

Therefore, what you want is something like DCCP, that adds a layer of 
control to RTP. If we think that in addition to knowing the state of the 
media tools (SIP/SDP), it is useful to know whether or not the other end 
intends to send media in order to drive GUIs, we could send this 
requirement to the DCCP folks.

Conclusion: the indication you are asking for architecturaly belongs to 
the signalling plane, but not to SIP. It belongs to a protocol that is 
tighly coupled with the media stream.

Mark, am I starting to understand your "in-principle" concerns or am I 
still far away from that ;o)

Gonzalo

Mark Watson wrote:
> I did not say there were no use cases. You're selectively quoting me. 
> Nice try though :-)
> 
> I'll admit that the use-case I described (Q.SIG/Q.931 interworking) 
> might not be sufficiently important on its own to motivate this 
> indication - that doesn't mean there are no use-cases. But I believe the 
> principle should lead us to expect more use-cases to be identified in 
> future.
> 
> Well, perhaps we *are* repeating the discussion on sendrecv/inactive. I 
> must say it is not entirely clear to me what it means for a stream to be 
> in sendrecv mode but for there to be no media being sent i.e. there is 
> no implementation-independent definition of what these 'media tools' are 
> and what it means for them to be 'on' or 'off'. We can only presume that 
> 'on' means that the device is in some sense 'ready' to send or receive. 
> But what does it mean to the UAC that the UAS is 'ready' to send media ? 
> How is this different for the UAC from the state where the UAS is 'not 
> ready' to send media ?
> 
> What is important is whether media is actually being sent - this 
> information is not available at the signalling layer.
> 
> 
> This is not an architectural argument, but a treatment of the specific 
> issue of media clipping. Your description makes assumptions which, 
> conveniently, lead to the conclusion that the indication is not needed. 
> For example the assumption that local policy allows media to be played 
> indepedently of the session state. This assumption is not fundamental to 
> SIP - I think whether media should be played or not at any given time is 
> a local issue for the UA.
> 
> I agree that this indication is available at the media layer in the form 
> of RTP packet arrival (btw, we are assuming it will be available at the 
> media layer in all cases, whereas SIP is supposed to be agnostic about 
> what the media layer, described by the SDP, is/does - I'm not saying I 
> have an example in which this indication is not available, but it is not 
> inconceivable that there could be no difference at the media layer 
> between "no media being sent" and "media being sent, but happens to be 
> 'silent'" in some sense - 'silent' could mean many things in the context 
> of media other than voice/audio).
> 
> All you've argued above is that 'this is available at the media layer 
> and so would be redundant if added to the signalling layer as well', but 
> this is only true with some assumptions about the communication 
> available between media and signalling layers and assumptions that the 
> communication at media and signalling layers have similar properties in 
> terms of security, reliability etc.
> 
> ...Mark
> 
> 
>  > Cheers,
>  >
>  > Gonzalo
>  >