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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Dec 2002 09:22:46 -0500

My point is that the significance of the directionality should *not*, and need not, be context sensitive. 

	Paul

Christer Holmberg wrote:
> 
> 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
> 
> Paul Kyzivat wrote:
> 
> > 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
> >
> > William Marshall wrote:
> > >
> > > 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]
> > _______________________________________________
> > 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
_______________________________________________
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: "Peterson, Jon" <[email-masked]>
Date: Wed, 4 Dec 2002 03:46:02 -0500

This is not a simultaneous pickup issue - this is a simultaneous early media
(ringing, etc) issue. Big difference, I think. Agreed that it is irrelevant
who wins in simultaneous pickup.

But in simultaneous early media, if you have two forked destinations that
are both transmitting early media of ringing, it is difficult (shall we say
impossible?) to know which one you should be listening to in order to avoid
clipping - you can't know which one will be answered (let alone which would
be answered first if both destinations happen to pick up). Obviously, the
problem is compounded as more destinations are added.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: Tuesday, December 03, 2002 7:24 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] Re: Early media draft
> 
> 
> Jon Peterson wrote:
> > In the case in which a request is forked, and two media 
> streams are returned
> > to the UAC from different UASs, which media stream MUST the 
> UAC play?
> 
> Clearly it MUST play the one for which the 200-OK is in transit. :-)
> 
> I recall that simultaneous pickup by multiple extensions was an early
> problem with ISDN implementations, too.  Which one wins is somewhat
> irrelevent.
> 
> Bill Marshall
> [email-masked]
>