Subject: [Sipping] Last Call: 'The Early Session Disposition Type for the Session Initiation Protocol (SIP)' to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 05 Apr 2004 14:45:30 -0400

The IESG has received a request from the Session Initiation Proposal 
Investigation WG to consider the following documents:

- 'The Early Session Disposition Type for the Session Initiation Protocol 
   (SIP) '
   <draft-ietf-sipping-early-disposition-01.txt> as a Proposed Standard
- 'Early Media and Ringing Tone Generation in the Session Initiation 
   Protocol '
   <draft-ietf-sipping-early-media-01.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-04-19.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sipping-early-disposition-
01.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-early-media-01.txt

_______________________________________________
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: Fri, 09 Apr 2004 16:59:55 -0400

I just read thru this again. I found one loose end. In section 4:

    Sending early media using a different offer/answer exchange than the
    one used for sending regular media helps avoid media clipping in case
    of forking. The UAC can reject or mute new offers for early media
    without muting the sessions that will carry media when the original
    INVITE is accepted. The UAC can give priority to media received over
    the latter sessions. This way, the application server model
    transitions from early to regular media at the right moment.

There is one case where the UAC still may have difficulty knowing which 
media to render - the case when multiple 200 responses make it back to 
the UAC, because multiple UAS's answered at almost the same time. This 
is similar to the case of receiving multiple early media streams in the 
gateway model - you can't necessarily decide which media stream matches 
which sip message, so if the intent is to hang up on one call and retain 
the other, it may take time to figure out which was the right media 
stream to play.

I don't know that this changes the arguments in a material way. An 
implementation that wants to cover all the bases will in this case want 
to take some of the same remediation steps as in the gateway case, which 
is a lot of pain. Most likely the typical approach will be to ignore the 
problem on the assumption that it will rarely happen, and that clipping 
is acceptable in that case.

I don't have strong feelings if this should be mentioned in the draft or 
not.

	Paul