Early or Late media

Hi all,

I know this is a SIP dedicated mail list and not designed
for IMS
related questions but I do not know where else I could
post.

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?

Thanks in advance,

Simon



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

Regards,

Simon

On 12/14/07, Dean Willis <dean.willissoftarmor.com> 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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

...
> In IETF and general IMS environments (AFAIK), there is
no 
> expectation that early media will be buffered. 

Brian Stucker's
draft-sipping-stucker-media-path-middleboxes-00 does mention
a
situation where queuing can occur with 'latching' (commonly
done by SBCs when
they do 'hosted NAT traversal'):

   ...
   13.  Media from the UAS is relayed to the UAC.  It is up
to local
        policy at the media relay as to whether or not
packets that had
        arrived from the UAS for the UAC are queued or
dropped prior to
                                             ^^^^^^
        the UAC's address/port information being updated in
step 11.
   ...

This might be what Simon was thinking about (or had heard
about).

-d

> 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://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

inline:

Simon Flannery wrote:
> Hi all,
> 
> I know this is a SIP dedicated mail list and not
designed for IMS
> related questions but I do not know where else I could
post.
> 
> 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

buffer? as in, the network would hold the media and
delivered to the 
called party only after 200 OK? No IETF spec makes that
recommendation.

> - The received media is buffered until at least the
first invited user
> accepts the invitation

As above.

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

SIP says that the calling UA must be prepared to accept
media after 
sending an offer. The called UA has to be prepared to
receive after 
sending the answer. There is nothing about buffering.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall
St.
Cisco Fellow                                   Edison, NJ
08837
Cisco, Voice Technology Group
jdrosencisco.com
http://www.jdrosen.net 
                       PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip