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

From: "Mark Watson" <[email-masked]>
Date: Thu, 3 Apr 2003 13:19:08 +0100

Gonzalo, all,

This addition to H.248 would certainly help with this problem, and indeed
addresses one of the reasons why I argued this flag was necessary. Note that
the mail from Christer suggests a way forward, but this is not completely
supported in H.248 yet.

Obviously, this solution can 'work', but I am still not sure it is a good
design.

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.

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.

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.

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.

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 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.

...Mark

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 01 April 2003 08:28
> To: Taylor, Tom-PT [CAR:5N00:EXCH]
> Cc: [email-masked]; Jon Peterson; Watson, Mark [MOP:EP10:EXCH]
> Subject: Re: [Sipping] Early media; a summary after the IETF
> 
> 
> Tom,
> 
> yes, this was mentioned in the meeting.
> 
> In any event, it is important that H.248 supports this type 
> of message 
> (generate ringback until media arrives), since it is needed 
> regardless 
> of any new flags or extensions that we could come up with. It 
> would be 
> good if somebody could work on that.
> 
> Thanks,
> 
> Gonzalo
> 
> Tom Taylor wrote:
> > Your charts do not reflect an important difference between MGCP and 
> > Megaco/H.248. In MGCP, it is possible to tell the MG to 
> automatically 
> > terminate application of ringing tone upon detection of 
> incoming media.  
> > In Megaco/H.248, the media event is detected on one 
> termination, but the 
> > ringing tone is being applied to another.  This means that 
> the MG has to 
> > report media detection to the MGC, and then the MGC has to 
> request that 
> > ringing tone application be stopped.  It has occurred to me upon 
> > reflection that there might be a way around this, but for 
> the moment 
> > that is the case.
> > 
> > Gonzalo Camarillo wrote:
> > 
> >> Folks,
> >>
> >> here you have a summary of what happened in the IETF 
> regarding early
> >> media.
> >>
> >> We planned to have an ad-hoc meeting, but since we managed 
> to get more
> >> meeting time than expected for this issue and some of the persons
> >> involved in the mailing list discussions were not available for an
> >> ad-hoc meeting (some of them were not even in San 
> Francisco), we did not
> >> finally have the ad-hoc.
> >>
> >> Regarding the discussions during the second SIPPING 
> session, the main
> >> input was slide number 3 of
> >>
> >> 
http://www.softarmor.com/sipping/meets/ietf56/slides/Gonzalo-sipping-early-m
edia.ppt 
>>
>>
>> That slide does not discuss the encoding issue. It focuses on the
>> requirements or the gains that adding a SIP "there is media coming" (or
>> "don't generate local ringback") indication would bring.
>>
>> The conclusion of that slide is that a message with "generate local
>> ringback until media arrives" should be provided by the protocol (e.g.,
>> MGCP or H.248) between the MG and the MGC **REGARDLESS** of whether or
>> not we create a "there is media coming" flag.
>>
>> Therefore, assuming that the MG is in accept-media state as soon as the
>> INVITE is sent, the only gain that a "there is media coming" would bring
>> would be saving one message from the MGC to the MG every time a 180 with
>> a flag is received. The gain is zero for 180 responses without the flag.
>>
>> The question is: are people after this optimization (saving of one
>> message in some circumstances) or there is somebody with something else
>> in mind?
>>
>>
>> In any event, the conclusion of the meeting was that I will be gathering
>> use cases where a "there is media coming" flag would be useful. Please,
>> send any use case you have in mind and I will compile them in a
>> document. We hope that such a document help us figure out which
>> requirement is missing.
>>
>> We also may organize a conference call in some weeks to further discuss
>> the issue, if needed.
>>
>> Thanks,
>>
>> 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
>>
> 
> _______________________________________________
> 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: Thu, 03 Apr 2003 15:49:40 +0300

Hi Mark,

Just a short question: what do you mean "is not completely supported in
H.248 yet"? It's a package, which has been standardized, so from that
point of view I think it as "supported" as anything else...

Or, did I missunderstand you?

I would also like to hear your arguments why/what you don't think is
good design? The fact that in H.248 an event can stop a signal, or what?

I do agree, which I also mentioned in the mail, that there may be some
issues. Those, however, are more related to the Context model.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 04 Apr 2003 12:37:27 +0300

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". 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.

> 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.

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

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.

> 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 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.
> 
> 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.

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*.

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

Thanks,

Gonzalo