Subject: Re: [Sipping] Re: Early media draft

From: William Marshall <[email-masked]>
Date: Wed, 27 Nov 2002 10:43:29 -0500 (EST)

Paul wrote:
> Beyond that, I am not attempting to say anything about what you should *do* 
> with the media you receive, or how that relates to locally generated media. 
> But I don't think you should be preempting locally generated ringback with 
> media received from an *inactive* stream.

I still believe the basic requirement is to avoid clipping.  If that
translates into a requirement to not use "a=inactive", so be it.

But I agree that the distinction between *permitted* and *obligated*
is an important one and needs to be specified.

Bill Marshall
[email-masked]

-----original message-----
Date: Wed, 27 Nov 2002 09:08:45 -0500
From: Paul Kyzivat <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sipping] Re: Early media draft

Bill - comments below.

	Paul

William Marshall wrote:
> 
> Paul wrote, in part:
> > Look at what I wrote in my earlier message. It doesn't behave at all like
> > the above. [clipping the "Hello" and getting two upset customers]
> 
> I didn't see in your earlier message that you weren't doing the
> a=inactive with the first offer.  As long as you don't need to
> do an extra offer/answer after pickup, then I'd agree your procedures
> will formalize the proper behavior of a UA.  The key item is having
> media allowed by the SDP without it being required to be sent.
> 
> As for the separate issue with ringback.  For a "normal" call, where
> the UAC does locally generated ringback, there is still the race condition
> where media arrives after the 180-Ringing and before the 200-OK.
> So the UA needs to be able to pre-empt local ringback to begin
> playing the media as soon as it arrives.  This is the same issue
> as receiving media on an inactive stream - don't clip it.

My point was to define clearly when you are *permitted* to send, and when 
you are *obligated* to receive based on the content of offers and answers. 
Based on these clarifications, you ought not be receiving when the stream 
is inactive, and so ought not be rendering what you aren't receiving.

Beyond that, I am not attempting to say anything about what you should *do* 
with the media you receive, or how that relates to locally generated media. 
But I don't think you should be preempting locally generated ringback with 
media received from an *inactive* stream.
_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Nov 2002 12:35:18 -0500

I don't have a problem discussing when it is/isn't appropriate to use inactive, or what the implications of doing so are. But I do believe it is important to honor the intent of the directionality specifications.

If you offer me sendrecv, but I answer you with inactive, then you should not send me anything. If that results in clipping, so be it. While the stream is inactive, I may well not read from it at all. Depending on the type of transport, if you write to it there could be a variety of different error conditions. (Of course in the case of RTP, I still must read the RTCP, but that is all.)

	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Nov 2002 19:58:24 +0200

Hi,

I think it also important to remember that in some cases "inactive" really does mean that we shall not pass any media. Call hold is one example. So, now "inactive" would have a little different "meaning" depending on the state of the call...

Regards,

Christer Holmberg
Ericsson Finland