Subject: [Sip] Early or Late media

From: "Simon Flannery" <[email-masked]>
Date: Thu, 13 Dec 2007 13:32:06 +0900

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://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 Dec 2007 14:49:44 -0600

> 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

---

From: "Simon Flannery" <[email-masked]>
Date: Fri, 14 Dec 2007 10:46:55 +0900

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

Regards,

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Dec 2007 00:13:03 -0800

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Dec 2007 17:39:02 -0500

inline:

> 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

As above.

> 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
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com