Subject: [Sipping] A Test Balloon For AS generated Early Media: EMIND

From: "Brian Stucker" <[email-masked]>
Date: Thu, 16 Nov 2006 12:21:33 -0600

All,

I think I have a way to fix application server generated early media,
which I believe makes up a great deal of the solvable early media
interactions we have today. This is early media triggered by some
service in the SIP network that is supplied by a network controlled
media server to the originating client. I'm looking for comments/poking
of holes/support.

To my mind, there are three major problems to be solved with application
server generated early media: getting the middle out of the way of the
end-to-end SDP negotiations, ensuring the middle has a chance at having
the client render the intended media, and getting the ordering correct.

Here's the proposal to address these areas:

- The UAC generates an INVITE as it always has, except that it includes
a supported tag denoting support for the early media model in this
proposal (let's use the option tag "emind" - early media indicator for
the sake of argument).
- If an application server/proxy wants to trigger some sort of network
generated early media back to the UAC, and it sees the "emind" supported
option tag, it does so by generating a 183 message back to the UAC with
an Alert-Info header that contains a SIP URI of the media resource it
wishes the UAC to connect to.
- Upon receiving the 183 message back with the Alert-Info header
containing the SIP URI to connect to, the UAC generates another INVITE
to the SIP URI from the 180 Alert-Info header. It may reuse the IP/ports
from the original SDP offerin the first INVITE request for this early
media offer if it so wishes (might be some issues with ICE processing
here), however, it should set a different dynamic RTP payload type on in
the SDP for this early media offer (more on this later).
- The UAC now may negotiate SDP between the two endpoints entirely
separately. It should know the exact state of each dialog and only
end-to-end SDP exchanges should be occurring on the original INVITE
dialog. The network media server would be contacted by the UAC for the
early media the application server wanted presented and able to answer
the early media INVITE to begin early media playback on that dialog.
- In the meantime, the UAC now knows which packets are transitional or
final media, and which ones are eary media because the RTP payload types
are different. When the UAC sees final media coming from the first,
end-to-end INVITE it can either wait for the 200 OK to comeon that
dialog or switch over immediately to that media stream and BYE the early
media INVITE.

It is expected that the UAC's local outbound proxy will strip any
Alert-Info headers from untrusted sources prior to sending them to the
UAC today. Also, there would need to be a change to the Alert-Info
syntax to allow a SIP URI. The forking issue should abate on the client
as it can ignore any forking on the end-to-end INVITE as far as knowing
whether or not it should revert to local ringback or not, and a q-value
could be used to get the ordering right for early-media dialogs.

Thoughts?

Regards,
Brian

_______________________________________________
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, 17 Nov 2006 15:13:51 -0500

Brian,

Is there a reason you propose something new like this in preference to 
the Application Server model of early media specified in RFC 3960?

While apparently not implemented, it does have the advantage of having a 
spec that is already done. Both it and what you propose present some 
implementation/deployment challenges. Yours is probably somewhat simpler 
to implement, but is that enough to be worth the trouble? If so, should 
we also deprecate the application server model?

	Paul