Subject: RE: [Sipping] Early media; a summary after the IETF

From: "Mark Watson" <[email-masked]>
Date: Fri, 4 Apr 2003 11:37:06 +0100

Hi Gonzalo,

Responses inline...

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 04 April 2003 10:37
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; [email-masked]; Jon Peterson
> Subject: Re: [Sipping] Early media; a summary after the IETF
> 
> 
> Mark,
> 
> > My other point, which seems not to have been captured in Gonzalo's 
> > slides (although I don't know if it was discussed at the 
> meeting), was 
> > that as a general principle, the status of the media stream 
> should be 
> > visible at the signalling layer. This is the case in all the other 
> > call/session control protocols that I know of.
> 
> I do not buy the argument "since others did it, let's do it".

That's not my argument. My argument is that looking at the architecture of
the system and what is appropriate to each layer, I think that this kind of
functional indication is appropriate to the signalling layer, not the media
layer. I just point out that other similar systems have come to the same
conclusion.

I'm happy to consider any achitectural arguments you have to the contrary,
but noone has presented any yet.

> I'd rather 
> analyze if what they did is applicable or not to our 
> particular problem. 
> More inline.
> 
> > The current status of SIP seems to be that whether there is media 
> > present or not is indicated only at the RTP layer, by the physical 
> > presence or otherwise of RTP packets.
> 
> We have already discussed this in the past. In the first 
> version of the 
> draft, I discussed that SDP provided only the status of the 
> media tools 
> at the end points (i.e., the media tools are on and off). I 
> proposed to 
> enhance this indications to convery situations like "media 
> tool on, but 
> I will not be sending media for the time being". after 
> analyzing it, we 
> all agreed that more granularity was not needed.
> 

I am not sure that the principle was addressed in that debate, just that the
particular proposal of using SDP status values for this was not agreed.

> > This creates the problem that deliberate absence of media is 
> > indistinguishable at the UAC from an error case in which 
> media has been 
> > blocked due to some network issue/NAT problem etc. At the 
> very least 
> > this makes debugging more difficult.
> 
> You have RTCP. The sending side will always know whether there is an 
> error. What you are proposing does not actually help debugging. Let's 
> say my SIP phone sends you a signalling message saying "I will be 
> sending media", but I remain silent in front of my 
> microphone... now you 
> will think that there is an error in the network, when everything is 
> perfectly normal.

Well, RTCP is optional. The fact that there may not be RTP packets when in
fact the sender is intending to send media (it just happens to be silent)
surely argues that using the presence/absence of RTP to indicate the media
status is even more unreliable!

> 
> > In addition, since this is the principle which has been 
> adopted by so 
> > many other call/session control protocols, then a gateway 
> interworking 
> > from one of these to SIP will not have the information necessary to 
> > simply map to indications in appropriate backwards 
> signalling messages. 
> > For example in mapping a SIP 180 to a Q.SIG or Q.931 ALERTING, I am 
> > forced to always provide in-band media (ringtone or media 
> received from 
> > the UAS) and indicate this in the ALERTING/Q.931, whereas 
> if I had an 
> > indication at the SIP layer I could take advantage of this 
> to indicate 
> > no in-band media in the ALERTING (in some cases) and save 
> myself on tone 
> > generation.
> 
> As far as I know, Q.931 lets you send ALERTING with no 
> indication, but I 
> do not know any example where the network uses this message. Where is 
> this used?
> 

You can probably get a clearer example from Q.SIG, but at least in Q.931 the
ALERTING will be sent with no Progress Indicator #1 or #8 in the case of an
end-to-end ISDN call (which can still be speech or 3.1kHz audio). This means
there is no in-band media & the user will not be connected to the backwards
media path. See Q.931 5.1.2 & Q.699. According to Q.699 this can even happen
on an ISDN to non-ISDN call, though I'm not sure I believe this is used.

If I have no early media on the SIP side & the call is from an ISDN terminal
then I could send an ALERTING with no in-band media. But only if I *know*
there will be no in-band media. I guess on receipt of some RTP I can send a
PROGRESS with PI#8, but this is my point about mixing layers.

> In any event, you will have the RTP-200 OK race condition. 
> Therefore, if 
> you do what you are saying (ALERTING + no indication), you will have 
> media clipping.
> 

Yes, but also I think there are scenarios in which policy dictates that
there should be no backwards media allowed before answer (e.g. when the UAS
is 'untrusted' in some sense), answer being the point at which the caller is
willing to start paying. You have to live with (or mitigate) clipping in
these cases anyway.

> > Finally, if I want to secure the implicit indication of 
> media then I 
> > need to secure the RTP stream itself (which is not 
> otherwise required in 
> > all applications). To secure a SIP-layer indication I have all the 
> > SIP-layer security stuff available.
> 
> I do not understand what you are saying here. If we do not 
> have a flag, 
> it does not matter whether or not you secure SIP, nobody will know 
> anything about the media path. If you have the flag, you have 
> to secure 
> SIP. Otherwise you coule leak this information (which I do 
> not think it 
> is very sensitive, but anyway)... therefore, the only thing 
> the addition 
> of the flag could do is worsen the situation... never improve it.
> 

I meant integrity, not confidentiality. If I want to secure the integrity of
the existing 'implicit' indication at the media layer, I need to secure the
media, which I might not otherwise need to do. If I want to secure the
integrity of a SIP-layer indication, I need to secure SIP, which I am likely
to do sooner than securing the media itself in many cases. You basically
bring forward the requirement to secure the RTP stream - some people might
argue this is a good thing.

> 
> > I am not arguing that these examples alone justify such an 
> indication, 
> > but rather that as a general principle this information should be 
> > signalled explicitly in SIP, not implicitly by the presence 
> of RTP packets.
> > 
> > I accept that the SIPPING meeting was not convinced that enough 
> > examples/use-cases had been presented to justify the 
> indication, and if 
> > this remains the case then I guess nothing will be agreed. 
> But as I feel 
> > these all stem from a more general principle, I think over 
> time we will 
> > continue to see more examples emerge.
> 
> I would like to know if the only reason you want such a flag 
> is because 
> you "fell" that it is the right thing to do (definitively an 
> acceptable 
> position) or if you have a use case where you *actually* need 
> such a flag.
> 

Well, both. The existance of an H.248 solution takes away one of the 'actual
needs' and the Q.SIG/Q.931 case above, though valid, is not of
earth-shattering importance, so I guess I am now arguing more from an 'in
principle' position.

> The only use case I have been able to think of so far is the 
> saving of a 
> signalling message from the MGC to the MG in the situation previously 
> described... but I would like to know if people have more use cases.
> 
> 
> The only extra use case that people have come up with is the network 
> scenario where RTP-200 OK race conditions are not considered 
> important. 
> That is, they are ignored. In that case, signalling will drive the MG.
> 
> People working with that type of network have already what they want: 
> the SDP direction attribute. Therefore, if that is the requirement 
> people are after, it is already solved. They have their flag 
> *already*.
> 

Well, no, because a normal SIP UAS which does not generate early media will
not set the media stream to 'inactive' to indicate this.

> And if people are thinking of another scenario(s), please speak up.
> 
> Thanks,
> 
> Gonzalo
> 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 04 Apr 2003 14:58:15 +0300

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.

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)?

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.

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?

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: Christer Holmberg <[email-masked]>
Date: Fri, 04 Apr 2003 15:28:37 +0300

Hi,

> in the signalling layer.

In this case I think my arguement that we should establish an early dialog
before we are required to accept (at least before we are required to play) any
media is even stronger. If we receive an answer, with the direction set to eg
"sendrecv", we KNOW that node MAY send early media. But, we don't know anything
about the remote node (we don't even know who it is) at the moment we send the
INVITE, and there are reasons we don't want to be required to play media
received from who know where.

I know it was said that receiving and playing media are two separate issues,
and that 3261 basically only requires us to only receive media (Gonzalo
confirmed that in another mail, I think), but my point is that it would give
nodes a reason to send their SDP as soon as possible - at least if they intend
to send early media, but also if they don't intend to (to avoid media clipping
if they send the remote SDP together with 200 OK). At the previous SIPit I had
some talks with Rohan about the sending of SDP. 3261 currently says that if
there is no SDP in the INVITE, one MUST be sent in the first reliable response.
However, IF there is a SDP in the INVITE, there is currently no requirement
when the answer SDP shall be sent - as long as it is sent before, or together
with, the 200 OK. Now, there are cases where a UAS eg simply can't send an SDP
in the first reliable provisional response, which it is required to do if there
was no SDP in the INVITE. So, instead of having these MUSTs I think it would be
much better to say that "a UAS should send its SDP as soon as possible".

Of course we still have the issue related to forking, media mixing etc, but I
don't think we can solve that (I really don't like the idea of sending lots of
pre-session UPDATEs, because that will cause other kind of race conditions),
but if we recommend SIP nodes to not send early media (PSTN gateways will of
course often do it) in the first place that may not be a really big problem in
real-life networks.

Regards,

Christer Holmberg
Ericsson Finland

> My initial arguments are:
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 04 Apr 2003 15:57:09 +0300

Christer,

if you need to get the remote SDP before acepting any media, you should 
use preconditions. You can define a new precondition type and use the 
framework defined in RFC 3312.

If you do not use preconditions, the UAS is free to send a 200 OK 
without any previous provisional response, as you know.

In any event, the draft says that systems sending early media using the 
gateway model send a provisional response with the SDP. If you want to 
make that recommendation even more explicit, let me know.

Anyway, this is not very much related to the "in-principle" discussion 
at hand.

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: Christer Holmberg <[email-masked]>
Date: Fri, 04 Apr 2003 16:04:48 +0300

Hi,

> framework defined in RFC 3312.

So, the "on/off" thing is only from a UAC point of view?

> without any previous provisional response, as you know.

Of course. I was only talking about recommendations (and, from my experience I would
say that most terminals mostly do send one or more 18x responses).

> make that recommendation even more explicit, let me know.

Well, it's so not about which model is used (the UAS probably doesn't know which
model the UAC uses, anyway), but more general SIP behaviour recommendation.

> Anyway, this is not very much related to the "in-principle" discussion

Sorry :) I should have put it in a separate mail, but since it was related to the
"on/off" issue (at least I though so) I decided to put it in the same mail.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Cary FitzGerald <[email-masked]>
Date: Sun, 06 Apr 2003 22:33:21 -0700

Can you point out where in RFC1889/1890 RTCP is described as 
optional?  RTCP has a number of uses; this is one.

Cary.

>> You have RTCP. The sending side will always know whether there is
>> an  error. What you are proposing does not actually help
>> debugging. Let's  say my SIP phone sends you a signalling message
>> saying "I will be  sending media", but I remain silent in front of
>> my
>> microphone... now you
>> will think that there is an error in the network, when everything
>> is  perfectly normal.
>
> Well, RTCP is optional. The fact that there may not be RTP packets
> when in fact the sender is intending to send media (it just happens
> to be silent) surely argues that using the presence/absence of RTP
> to indicate the media status is even more unreliable!

---

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

Folks,

RTCP is mandatory, and it MUST be sent. RTCP is useful to perform 
inter-media synchronization, to monitor the quality of the transmission 
and to elaborate statistics.

Further RTCP discussions can take place in MMUSIC, if needed.

Gonzalo

Cary FitzGerald wrote:
> Can you point out where in RFC1889/1890 RTCP is described as optional?  
> RTCP has a number of uses; this is one.
> 
> Cary.
>