Subject: RE: [Sipping] Re: Early media: a summary

From: "Francois Audet" <[email-masked]>
Date: Tue, 3 Dec 2002 13:50:10 -0800

> One could agree that the only scenario where this will be 
> used is when we are interworking with PSTN, and that early 
> media should not be used between SIP phones.
> 
> However, I am not sure I agree with the statement that it 
> only belongs in the ISUP/SIP draft. The reason for that is 
> that this issue doesn't only affect PSTN gateways - it also 
> affects the normal SIP phones communicating with the PSTN 
> gateways. I think we want a solution which allows SIP phones, 
> as well as PSTN gateways, to know and/or indicate if there is 
> early media or not. And, since a SIP phone may not know if it 
> communicates with a PSTN gateway or another SIP phone, and a 
> PSTN gateway may not know if it communicates with a SIP phone 
> or another PSTN gateway, I think we need a generic solution.
> 
> And, if we first find a solution, we can then argue about in 
> which document to put it :)

I agree completely that early media, even if it only applied to
PSTN interworking, would have a ripple effect that would impact
SIP phones as well.

Furthermore, I really don't think it is satisfactory to document
early media only in the ISUP/SIP RFC. Many PSTN-SIP gateways
(if not the majority) are likely to be ISDN and Analog gateways.

The procedures therefore need to work for ISUP as well as for
Q.931 (and QSIG by extension).

From a SIP point-of-view, the signalling should look exactly the
same regarless of the type of PSTN gateway (ISUP vs. Q.931).

---

From: William Marshall <[email-masked]>
Date: Tue, 3 Dec 2002 18:32:45 -0500 (EST)

Francois (and Christer also) wrote:
> early media only in the ISUP/SIP RFC. 

I'll agree with this point.  Since the decisions do affect 
endpoints in general, the solution is worth documenting on its own.

However, after a long discussion last summer, there was consensus
on a solution to the basic problems of early media and local vs.
remote ringback.  Those decisions are documented in the sip-isup
draft, which is currently in the rfc editor's queue after having
been approved by the Working Group and the IESG.  I see no reason
to discard those decisions now, unless there has been some experience
to show that they don't work.  That should define the starting point,
and any additional functionality for "fully featured[?] early media"
should, in the simple cases, reduce to the design in sip-isup-06.

Bill Marshall
[email-masked]

-----original message-----
From: "Francois Audet" <[email-masked]>
To: "'Christer Holmberg'" <[email-masked]>,
        "'William Marshall'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>,
        "[email-masked]'" <[email-masked]>
Subject: RE: [Sipping] Re: Early media: a summary
Date: Tue, 3 Dec 2002 13:50:10 -0800 

same regarless of the type of PSTN gateway (ISUP vs. Q.931).
_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Tue, 3 Dec 2002 15:32:50 -0800

> However, after a long discussion last summer, there was 
> consensus on a solution to the basic problems of early media 
> and local vs. remote ringback.  Those decisions are 
> documented in the sip-isup draft, which is currently in the 
> rfc editor's queue after having been approved by the Working 
> Group and the IESG.  I see no reason to discard those 
> decisions now, unless there has been some experience to show 
> that they don't work.  That should define the starting point, 
> and any additional functionality for "fully featured[?] early 
> media" should, in the simple cases, reduce to the design in 
> sip-isup-06.

Yep, and I fully agree with you. The sip-isup-06 draft should be
the basis of whatever we define. That is one of the reason
I have a lot of concerns with the draft-camarillo-sipping-early-media draft.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 3 Dec 2002 15:57:56 -0800

> media" should, in the simple cases, reduce to the design in 

On that note...

sip-isup-06 (section 7.2.6) states the following:
   When a 180 is sent, it is assumed that any necessary
   ringback tones will be generated locally by the SIP user agent to
   which the gateway is responding (which may in turn be a gateway).

I believe that this statement is accurate and we shall not
introduce anything that contradicts it in the early-media draft.

---

From: William Marshall <[email-masked]>
Date: Tue, 3 Dec 2002 19:19:13 -0500 (EST)

Gonzalo wrote:
> That draft [sip-isup-06] says that the early media solution described is
> a "simple" one. We already anticipated at that point in time that a 
> fully-featured early media solution was in its way.

I don't see anything in the early media draft that extends this "simple" early
media, with the possible exception of a GUI interface that could just as
easily be driven off of an indication of media being received as from a
new attribute in the SDP.  So I think the requirements for "fully featured"
still need some work.

> I do not agree that early media is about PSTN interworking. Take
> Jonathan's draft on application server interaction and you will see
> several examples of early media.

Granted all multi-media sessions can be done using only early-media, by
delaying the 200-OK until just prior to the BYE.  But I don't see where
the application interaction draft is providing any examples that use
early media - and in several cases it seems to go out of its way to
avoid use of early media (e.g. INVITE from the prepaid server back to
the caller, establishing a new session for collecting the acct info).

> > And I continue to believe that end-to-end signaling of the mute button
> > is harmful, and should be discouraged.
> 
> Please, re-read the last proposal. You would not touch the media
> configuration when the user presses mute. But the intention attribute
> would give you a means to inform the other end that you have done so...
and in previous email on this thread:
> 1) The sender stops sending media: this can be signalled with the
> intention attribute. This way the receiver can distinguish this
> situation from a network dropping packets.

The end-to-end message that signals the changed intentions is exactly what 
I meant.  It causes additional load on the proxies in the signaling path
for little or no gain.  The interesting case is where no media is being
received, and the latest SDP says the sender intends to be sending it.
If the network is dropping packets, what makes you think the UPDATE w/SDP
won't be dropped too?  So you still have to deal with the situation of
questionable intentions and no media being received.

I further think your examples with video and GUIs only apply because
less work has been done on the video codecs than audio codecs -- silence
suppression, and packet loss concealment are two issues well studied
for audio that need solutions for video as well.  Attempting to "fix"
them by increasing the signaling overhead is not a good solution.

Bill Marshall
[email-masked]

-----original message-----
Date: Tue, 03 Dec 2002 17:23:31 +0200
From: Gonzalo Camarillo <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked]
Subject: Re: Early media: a summary

Bill,

inline:

William Marshall wrote:
> 
> Gonzalo,
> 
> I've read through your updated version 00 of the draft, and still have
> a number of major concerns with it.
> 
> First and foremost, we had a long discussion last summer on this email
> list during the last call on the sip-isup draft, leading to consensus
> on handling of early media and in-band-ringback.  I see no reason why
> the agreements of last summer need to be scrapped in favor of a complete
> new mechanism,  If there is some cruical flaw in the solution contained
> in draft-ietf-sipping-isup-06, please describe it.

That draft says that the early media solution described is a "simple"
one. We already anticipated at that point in time that a fully-featured
early media solution was in its way.

>
> Second, I believe the only real use of early media, as you have defined it
> in section 1, is for interworking with legacy systems, particularly the
> PSTN.  Numerous complex issues (which are not addressed in your draft)
> of e.g. early-media-on-hold, call-transfer of early media, etc, lead me
> to believe the concept should not be encouraged for SIP-SIP connections.
> And if the only real use is for interworking with the PSTN, again the
> proper place for the definition of how it is done is the sip-isup draft.

I do not agree that early media is about PSTN interworking. Take
Jonathan's draft on application server interaction and you will see
several examples of early media.

> (A SIP endpoint that wants to act like the PSTN can follow those rules too).
> 
> Media clipping is certainly a real problem, and needs to be addressed.
> But your "early media" definition in Section 1 is "from the moment the
> initial INVITE is sent until the UAS generates a final response".  The
> clipping problems occur between the UAS generating the final response and
> the UAC processing it.  Your new "a=intention" does nothing to solve
> the problem.  And section 6.2 should only be given as a bad example that
> should not be followed, since the additional offer/answer exchange after
> pickup will guarantee clipping.
> 

No with the intention attribute.

[WTM] ???

> Your example in section 2.3 sounds like a requirement for the equivalent
> of video comfort noise.  The equivalent of silence suppression would also
> be nice (i.e. how long to continue sending images of a blank wall?)

This has to do with video compression, not with a sender stopping
sending video.

> And I continue to believe that end-to-end signaling of the mute button
> is harmful, and should be discouraged.

Please, re-read the last proposal. You would not touch the media
configuration when the user presses mute. But the intention attribute
would give you a means to inform the other end that you have done so...
anyway, I guess what we have to decide is what I asked in my previous
mail (the one I sent a couple of minutes ago). Do you think it is
worthwhile resolving the first bullet of that mail?

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 04 Dec 2002 10:03:11 +0200

Folks,

all the proposals I am getting from you (privately or in the mailing
list) consist of signalling the intention of a sender using a status
code rather than a new offer/answer.

I see two problems with this.

1) it goes against SIP semantics. In SIP *only* means *alerting*. 180
does not tell you anything about the media

2) why is it better than a SIP-friendly mechanism like UPDATE? Remember
that 1xx-PRACK-200 OK is heavier than UPDATE-200 OK in some situations.

We are trying to resolve the same thing. The only difference is that I
am trying to make general proposals that work in any scenario (like
switching from local to remote ringback and then back again), and your
proposals have a narrower scope.

And if you think that more complex situations (like switching from local
to remote ringback and then back again) will never appear in PSTN
interworking, you are most likely right. But remember that this is not
*only* about PSTN interworking. It is also about video and multimedia.

Note that your proposals involve two fewer messages in the most common
PSTN interworking scenario. However, in a general early media solution
we prefer generality over optimizations like these.

Thanks for the feedback,

Gonzalo