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

From: William Marshall <[email-masked]>
Date: Tue, 26 Nov 2002 17:11:01 -0500 (EST)

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.

Given this essential behavior, we can use it to simplify other cases.
In the case where an announcement is played, after some period of
ringback, the UAS can make use of the required bahavior above.  Just
send the announcement inband, and it will pre-empt the ringback at
the UAC.  But once a UAS does this, the UAC is probably thinking
the 200-OK is on its way, so the UAS needs to continue sending media 
(so it would generate an in-band ringback, if needed).

The lengthy discussion last summer during last call on the ISUP draft
resulted (at least as I understand the final text) in sending 180
if alerting was being done, and sending 183 if in-band media/ringback/
announcements were being sent.  This works fine, with the unfortunate
case of a UAS that doesn't know whether it will be generating inband
ringback or not - it can result in the UAC getting a locally generated
ringback then having it preempted by the remote ringback - unclean but
uncommon, and a fair tradeoff.

Bill Marshall
[email-masked]

-----original message-----
Date: Tue, 26 Nov 2002 13:33:28 -0500
From: Paul Kyzivat <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sipping] Re: Early media draft

William Marshall wrote:
> 
> Paul wrote:
> > .... When offering to begin sending, why shouldn't the
> > offerer wait for the answer before beginning to send? The offerer always
> > gets a form of confirmation with the answer. And it is possible that the
> > answer will say inactive.
> 
> While this approach makes it easy for the endpoint to set up the
> data paths through DSPs, etc, it causes a huge problem with post-pickup
> delay.  The problem is the extra offer/answer exchange needed after
> the destination answers.
> 
> Typical scenario goes like this:
>         called party:   answer phone, say "Hello"
>                         hear nothing, hangup
>                         (and is upset about a telemarketer calling)
> 
>         calling party:  hear ringback, then silence
>                         then call disconnects
>                         (and is upset about being billed for completed call)
> All because the media for the "Hello" wasn't sent because the offer/answer
> exchange had not completed in time.  And it is the calling party's UA that
> goofed.

Look at what I wrote in my earlier message. It doesn't behave at all like 
the above.

Assuming the calling party sent an offer in the invite with SENDRECV or 
RECVONLY (this would be the normal case I think), the calling party should 
immediately begin listening, and presumably playing out what is received, 
subject to interactions with ringback - a separate issue. But it doesn't 
enable sending until it receives the answer. This is no big deal. The caller 
will hear the "Hello", and the answer should normally be received in time 
so that the caller's response to the hello can be sent.

Meanwhile, the called party starts sending and receiving when it sends the 
answer, which is plenty soon to send the "Hello" and receive the response.

In all cases both ends are operating in a way consistent with the SDP they 
are exchanging.

> 
> There is already a race between the start of media packets and the 200-OK.
> It is likely in most cases that the media will arrive first, since it
> has fewer processing hops along the way.  Adding another round-trip
> signaling exchange makes the post-pickup delay problem far worse.

There are only extra round trips for more complex call flows, such as ones 
that explicitly set the stream inactive initially. This is presumably done 
for cause, so why second guess it?

	Paul
_______________________________________________
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 09:08:45 -0500

Bill - comments below.

	Paul

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