Subject: [Sipping] Forking, early media and ICE

From: "Eric Tremblay" <[email-masked]>
Date: Fri, 8 Jun 2007 16:50:42 -0400

I have been reading a lot lately about forking and early media. I am
trying to mix all of this with ICE and I now have a headache.

I read through the following mailing list threads: 
sip-> "the problem with PRACK" (march 2006)
sipping -> "Some thoughts on fixing early media" (july 2006)

And the numerous RFCs and drafts:
RFC 3960
draft-barnes-sip-em-ps-req-sol-00
draft-stucker-sipping-early-media-indirection-00
draft-stucker-sipping-early-media-coping-03

I don't think ICE was tackled in those discussions. I see important
complexity with ICE and forking when the initial offer is included in
the INVITE. It is maybe not protocol complexity but probably more
implementation complexity.

Here is what we should find in ICE-16 (from
http://www1.ietf.org/mail-archive/web/mmusic/current/msg05669.html)
<t>
When ICE is used with SIP, forking may result in a single offer
generating a multiplicity of answers. In that each, ICE proceeds
completely in parallel and independently for each answer, treating the
combination of its offer and each answer as an independent offer/answer
exchange, with its own set of pairs, check lists, states, and so on. The
only case in which processing of one pair impacts another is freeing of
candidates, discussed below in <xref target="sec-XXX"/>.
</t>

I see implementing this as quite complex, and being lazy, I would like
to simplify this. Seriously, we see many problems with more trivial
things (prack comes to mind).

Brian Stucker has proposed an interesting mechanism in the mailing list
(see
http://www1.ietf.org/mail-archive/web/sipping/current/msg11631.html)
that would simplify ICE & forking negotiation along with early media.
However, somehow it failed to get into his
draft-stucker-sipping-early-media-coping draft.

I like this mechanism. Maybe it was beaten to death for some reason on
the mailing list and I failed to see it, but the initial comments to it
were positive. Apologies if I am reviving something that should stay
buried.

Here is a quick recap of the proposed mechanism:

1) UAC: Send offerless INVITE
2) UAS: Seeing the peer supports rel1xx, send a 183 with an offer.
3) UAC: Send a PRACK with the answer
4) UAS: Received the PRACK with the answer, offer/answer exchange
completed, can notify user of incoming call (if there are no
preconditions).
5) UAC: If it receives a 18x from different endpoint due to forking,
then the client can now sanely handle the new leg and its early media.

So yes, it is somewhat a lightweight precondition mechanism, where the
destination notifies the user only when a full offer/answer exchange has
been done.

CONS:
- Depends on reliable 1xx
- Media clipping for devices that do not support prack and send their
offer in a reliable 1xx response.
- Potential clipping for devices that do support prack but send the
offer in a 180.
- Requires three additional messages (183, PRACK, 200 OK to PRACK)

PROS:
- 100% backward interoperable, nothing new is really added.
- Clients can now associate the early media with a specific endpoint
(different answer & rtp port for each)
- Clients can mute some early media in the answer if they can listen to
just one (a=inactive in the answer). 
- Devices that MUST play an announcement know when the user is able to
receive the stream ("by pursuing the call, you agree to pay these extra
fees", the device would know to play the stream when the client sends an
updated offer and forward the call only after the stream was fully
played)
- Simplifies A LOT ICE when forking is done.

I don't think this will solve everything (HERFP, world hunger, etc) but
it could be a step forward if the majority of devices implemented this.
I am willing to spend some time working on this (BCP or something else)
if people are interested.

Comments?

EricT

_______________________________________________
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: "Brian Stucker" <[email-masked]>
Date: Fri, 29 Jun 2007 15:25:34 -0500

Hi Eric,
 
I don't think using an offerless INVITE is really the best way to handle
early media interactions, although as you have pointed out, I once did
consider this model for discussion. All that this effectively does it
puts the onus on the other endpoint to initiate the SDP exchange and you
still wind up with many early media problems. In fact, since you don't
know where to stream media to the originator, you probably can't
effectively deal with early media at all for many endpoints that aren't
aware of what the originator is trying to do.
 
That's why I put together the early-media-indirection draft to try to
come up with another way of dealing with all of the SDP negotiation.
There's already a BCP of sorts for early media in RFC-3960 although I've
seen a number of implementations that ignore the document or,
particularly with the application server model, go a completely
different route of hacking up SIP dialog states and end-to-end SDP
negotiation to ensure that their media is what is rendered at the
originating client. Likewise, there seems to be only a loose adherence
to RFC-3960 judging from the responses received in the SIPit 19 activity
report:
 
---
Media

Here is a sample of how endpoint implementors replied when asked how
they handled early media from more than one leg:

*	We allow multiple RTP streams with an affinity to the last one.
*	First Media received is played until 200.
*	The first 183 will be honored in case of the UAC. The rest will
be dropped.
*	Allow media from only negotiated address. Ignore media until
negotiated (offer-answer exchanged).
*	Listen to most recently started stream.
*	All early media will passed on to the UA.
*	Pick the one who most recently sent me a criticial threshold of
media.
*	Play only one media stream and ignore others.
*	The last sdp received override previous one.
*	First 18x message goes through, rest dropped.
*	Open voice only with the first one, but answer all of the 18x.
*	We will use the first recieved.
*	I ignore early media.
*	All get relayed - (all rendered leave final choice to recipient
UA).
*	Last early media replaces previous.
*	We update media as the 18x's come in. 200OK media will be the
confirmed media channel.
*	Take the first.
---

Clearly there is confusion here.

For the application server model in particular, I think it really would
just be the most simple and direct approach to have the client use the
procedure in the early media indirection draft rather than go bonkers
trying to manage different SDP and RTP sources within the same SIP
dialog. Hopefully folks have had some more time to digest the material
in the draft since it's last presentation to the WG to come up with
comments or feedback as to why the suggested approach does or does not
work for them.
 
I would hope that the community would have an interest in closing this
long-standing problem area in SIP. Early media isn't going to simply
fade away as some have hoped. We're seeing other SDOs pick up this topic
in fits and spurts as well with varying results at understanding and
adapting SIP to their requirements.
 
Regards,
Brian

________________________________

	From: Eric Tremblay [mailto:[email-masked]] 
	Sent: Friday, June 08, 2007 3:51 PM
	To: sipping
	Subject: [Sipping] Forking, early media and ICE

	I have been reading a lot lately about forking and early media.
I am trying to mix all of this with ICE and I now have a headache.

	I don't think ICE was tackled in those discussions. I see
important complexity with ICE and forking when the initial offer is
included in the INVITE. It is maybe not protocol complexity but probably
more implementation complexity.

http://www1.ietf.org/mail-archive/web/mmusic/current/msg05669.html
<http://www1.ietf.org/mail-archive/web/mmusic/current/msg05669.html> ) 

	</t> 

	I see implementing this as quite complex, and being lazy, I
would like to simplify this. Seriously, we see many problems with more
trivial things (prack comes to mind).

	Brian Stucker has proposed an interesting mechanism in the
mailing list (see
http://www1.ietf.org/mail-archive/web/sipping/current/msg11631.html
<http://www1.ietf.org/mail-archive/web/sipping/current/msg11631.html> )
that would simplify ICE & forking negotiation along with early media.
However, somehow it failed to get into his
draft-stucker-sipping-early-media-coping draft.

	I like this mechanism. Maybe it was beaten to death for some
reason on the mailing list and I failed to see it, but the initial
comments to it were positive. Apologies if I am reviving something that
should stay buried.

	1) UAC: Send offerless INVITE 
	2) UAS: Seeing the peer supports rel1xx, send a 183 with an
offer. 
	3) UAC: Send a PRACK with the answer 
	4) UAS: Received the PRACK with the answer, offer/answer
exchange completed, can notify user of incoming call (if there are no
preconditions).

	5) UAC: If it receives a 18x from different endpoint due to
forking, then the client can now sanely handle the new leg and its early
media.

	So yes, it is somewhat a lightweight precondition mechanism,
where the destination notifies the user only when a full offer/answer
exchange has been done.

	CONS: 
	- Depends on reliable 1xx 
	- Media clipping for devices that do not support prack and send
their offer in a reliable 1xx response. 
	- Potential clipping for devices that do support prack but send
the offer in a 180. 
	- Requires three additional messages (183, PRACK, 200 OK to
PRACK) 

	PROS: 
	- 100% backward interoperable, nothing new is really added. 
	- Clients can now associate the early media with a specific
endpoint (different answer & rtp port for each) 
	- Clients can mute some early media in the answer if they can
listen to just one (a=inactive in the answer). 
	- Devices that MUST play an announcement know when the user is
able to receive the stream ("by pursuing the call, you agree to pay
these extra fees", the device would know to play the stream when the
client sends an updated offer and forward the call only after the stream
was fully played)

	I don't think this will solve everything (HERFP, world hunger,
etc) but it could be a step forward if the majority of devices
implemented this. I am willing to spend some time working on this (BCP
or something else) if people are interested.

	Comments? 

	EricT