Thank you Dean for your prompt response and making this source of
confusion sound so simple.

Regards,

Simon

On 12/14/07, Dean Willis <[EMAIL PROTECTED]> wrote:
>
> On Dec 12, 2007, at 10:32 PM, Simon Flannery wrote:
> >
> > I would like to check my understanding of Early and Late media also
> > know as Early (or Late) operating mode:
> >
> > - Using Early media, the inviting user may talk immediately, and the
> > core network should buffer the media before the invited user (or
> > users) accept the session
> > - The received media is buffered until at least the first invited user
> > accepts the invitation
> > - The buffered media is also sent to all users that accept the
> > invitation
> > - Conversely, Late media mimics a traditional phone call where the
> > inviting user must wait until at least one inviting user accepts the
> > session before being allowed to send media
> >
> > Is my understanding correct? Are any of the dot points in error?
> >
> >
>
> Welcome to one of the most confusing aspects among the many confusing
> aspects of SIP that were introduced by our attempts to compensate for
> the broken signaling model of ISUP. Personally, I think we
> unwittingly introduced a nightmarish level of complexity and should
> have just said "no! If you need two stage signaling, finalize the
> first stage with a 200 OK and then re-INVITE if the SDP changes for
> the second session." But we didn't do that, so we have what we have.
>
> IETF seems to use the terms "early media" and "early session",
> although I'm afraid I don't completely understand the nuances despite
> having struggled with them for many years.  I suspect I don't want to
> understand just because the whole thing hurts my delicate
> sensibilities. I'm told that RFC 3960 is a useful reference for this
> discussion.
>
> Both uses of "early" refer to the transmission of media before
> completion of some phase of the signaling. Sometimes this is mean to
> be "before completion of the offer/answer phase" (that is, after an
> "offer", but before an "answer", and sometimes (as defined in RFC
> 3960) before the completion of a final response (generally a 200) to
> an INVITE request.
>
> RFC 3960 uses the following definition:
>
>    Early media refers to media (e.g., audio and video) that is
> exchanged
>    before a particular session is accepted by the called user.
> Within a
>    dialog, early media occurs from the moment the initial INVITE is
> sent
>    until the User Agent Server (UAS) generates a final response.  It
> may
>    be unidirectional or bidirectional, and can be generated by the
>    caller, the callee, or both.  Typical examples of early media
>    generated by the callee are ringing tone and announcements (e.g.,
>    queuing status).  Early media generated by the caller typically
>    consists of voice commands or dual tone multi-frequency (DTMF) tones
>    to drive interactive voice response (IVR) systems.
>
> In IETF and general IMS environments (AFAIK), there is no expectation
> that early media will be buffered. Anything not received by a
> listener is expected to be discarded.
>
> However, OMA's Push to talk Over Cellular (POC) specification does
> (or at least did, the last time I looked) allow a predictive mode
> where a POC controller (which is for all practical purposes a SIP
> B2BUA with media handling) can "answer" on behalf of a POC terminal
> with which it has an active relationship. The POC controller then
> buffers media while it activates the radio bearer needed to send the
> media on to the terminating POC client. Since the POC controller has
> effectively "answered" the INVITE request with a terminal response
> and media answer, I don't believe this mode qualifies as "early
> media" by any of the definitions in use around the IETF.
>
> Good luck in sorting this all out.
>
> --
> Dean
>
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to