RE: [Sipping] Forking, early media and ICE

["Eric Tremblay" <[e-mail]>]

Hi Brian,

Thanks for your reply.

I agree, there is confusion when it comes to early media handling.
Furthermore, I think the industry is getting slower at adopting "fixes"
versus new features that bring added value. I think this is part of the
reason why 3960 is not yet widely adopted. As you have well documented,
some vendors rely on servers to manage and somewhat fix forking and
early media for the originator. Bad.

For offerless INVITE, could you further explain which "many early media
problems" you are refeering to? I think you have given more thought to
this than me :)

I was thinking that if the originator was using some mechanism to
indicate what it is trying to do (I am guessing you meant which type of
media it wants to use), then the terminator(s) should be able to figure
out what to do about this offerless INVITE. This could offer some
benefits of a two-stage negotiation while using just one offer-answer.

Your thoughts?

Best Regards,

EricT
 

-----Original Message-----
From: Brian Stucker [mailto:[e-mail]] 
Sent: June 29, 2007 16:26
To: Eric Tremblay; sipping
Subject: RE: [Sipping] Forking, early media and ICE

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:[e-mail]] 
	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 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
<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
<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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP