Subject: [MMUSIC] SDPCapNeg Issue #5: Media before answer

From: Flemming Andreasen <[email-masked]>
Date: Mon, 25 Jun 2007 13:14:42 -0400

The answerer may select a potential configuration containing parameters 
that require the offerer to receive the answer before he can process 
media correctly. The issue is explained in Section 3.8 in the SDP 
Capability Negotiation framework, where one possible solutions is 
outlined (preconditions), but not actually specified. The question was 
raised whether we want to say more about this issue and if we want to 
define additional solutions to it. For example, Jonathan Rosenberg 
suggested that use of ICE can help the answerer determine when the 
answer has been received by the offerer and hence it is safe to send 
media to the offerer.

The design team discussed this issue in Prague and agreed to elaborate 
slightly on the current text. It will be noted that the offerer can 
discard media until he receives the answer, if he wants to make sure he 
doesn't play garbage. If the offerer wants to avoid clipping on the 
other hand, he can play media as soon as it is received, but at the risk 
of playing garbage. To avoid both, a three-way handshake is needed (e.g. 
precondtion), however that is outside the basic SDP Capability 
Negotiation. We will add a note to mention the use of ICE (STUN) as a 
possible solution to this three-way handshake as well.

If you disagree with this, please let me know.

Thanks

-- Flemming

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Jun 2007 08:25:45 -0700

Was the use of a payload type for this, as mentioned in
draft-kaplan-mmusic-best-effort-srtp-01, considered and discarded?  I'm fine
if it was, I'm just asking.  It seemed useful although it only increases the
chances of not playing garbage (because you don't know until you get the
answer if the answerer understood that technique).

-d

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: Monday, June 25, 2007 10:15 AM
> To: mmusic
> Subject: [MMUSIC] SDPCapNeg Issue #5: Media before answer
> 
> The answerer may select a potential configuration containing 
> parameters that require the offerer to receive the answer 
> before he can process media correctly. The issue is explained 
> in Section 3.8 in the SDP Capability Negotiation framework, 
> where one possible solutions is outlined (preconditions), but 
> not actually specified. The question was raised whether we 
> want to say more about this issue and if we want to define 
> additional solutions to it. For example, Jonathan Rosenberg 
> suggested that use of ICE can help the answerer determine 
> when the answer has been received by the offerer and hence it 
> is safe to send media to the offerer. 
> 
> The design team discussed this issue in Prague and agreed to 
> elaborate slightly on the current text. It will be noted that 
> the offerer can discard media until he receives the answer, 
> if he wants to make sure he doesn't play garbage. If the 
> offerer wants to avoid clipping on the other hand, he can 
> play media as soon as it is received, but at the risk of 
> playing garbage. To avoid both, a three-way handshake is 
> needed (e.g. precondtion), however that is outside the basic 
> SDP Capability Negotiation. We will add a note to mention the 
> use of ICE (STUN) as a possible solution to this three-way 
> handshake as well. 
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 26 Jun 2007 11:35:31 -0400

> answer if the answerer understood that technique).
It's mentioned as one possible approach in Section 3.8 (but not mandated).

-- Flemming

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 26 Jun 2007 16:54:51 -0500

The preconditions approach to me seems like the least likely approach to
be used in the real world.
 
I really see only two practical way forward:

1.	
	You have to wait for the answer before playing anything. For
this to work, we'd effectively have to rely on provisional responses
including the SDP-answer (and not include the answer in the 200, since
it would cause clipping). That in itself would be a change for many SIP
clients who never tought it necessary to provide an answer before 200
before (at least, they didn't think they needed it).
2.	
	Use the different payload type as per our kaplan draft.

My take is that option 1 is the more likely to have wide support. But we
should explain it a bit.
 
Option 2 is interesting, in a geeky way, and probaly better than
pre-conditions. But if people can live with 1, it seems much simpler.
 
My 2 cents.

________________________________

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: Tuesday, June 26, 2007 08:36
	To: Dan Wing
	Cc: 'mmusic'
	Subject: Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer

	Dan Wing wrote: 

		Was the use of a payload type for this, as mentioned in
		draft-kaplan-mmusic-best-effort-srtp-01, considered and
discarded?  I'm fine
		if it was, I'm just asking.  It seemed useful although
it only increases the
		chances of not playing garbage (because you don't know
until you get the
		answer if the answerer understood that technique).

	It's mentioned as one possible approach in Section 3.8 (but not
mandated). 
	
	-- Flemming 

		-d

			-----Original Message-----
			From: Flemming Andreasen
[mailto:[email-masked]] 
			Sent: Monday, June 25, 2007 10:15 AM
			To: mmusic
			Subject: [MMUSIC] SDPCapNeg Issue #5: Media
before answer
			
			The answerer may select a potential
configuration containing 
			parameters that require the offerer to receive
the answer 
			before he can process media correctly. The issue
is explained 
			in Section 3.8 in the SDP Capability Negotiation
framework, 
			where one possible solutions is outlined
(preconditions), but 
			not actually specified. The question was raised
whether we 
			want to say more about this issue and if we want
to define 
			additional solutions to it. For example,
Jonathan Rosenberg 
			suggested that use of ICE can help the answerer
determine 
			when the answer has been received by the offerer
and hence it 
			is safe to send media to the offerer. 
			
			The design team discussed this issue in Prague
and agreed to 
			elaborate slightly on the current text. It will
be noted that 
			the offerer can discard media until he receives
the answer, 
			if he wants to make sure he doesn't play
garbage. If the 
			offerer wants to avoid clipping on the other
hand, he can 
			play media as soon as it is received, but at the
risk of 
			playing garbage. To avoid both, a three-way
handshake is 
			needed (e.g. precondtion), however that is
outside the basic 
			SDP Capability Negotiation. We will add a note
to mention the 
			use of ICE (STUN) as a possible solution to this
three-way 
			handshake as well. 

			Thanks
			
			-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 26 Jun 2007 18:22:11 -0400

Francois Audet wrote:
> The preconditions approach to me seems like the least likely approach 
> to be used in the real world.
>  
>       this to work, we'd effectively have to rely on provisional
>       responses including the SDP-answer (and not include the answer
>       in the 200, since it would cause clipping). That in itself would
>       be a change for many SIP clients who never tought it necessary
>       to provide an answer before 200 before (at least, they didn't
>       think they needed it).
>
You'd have to include the answer in both the provisional response and 
the 200, unless you use reliable provisional responses.

> My take is that option 1 is the more likely to have wide support. But 
> we should explain it a bit.
I'll include an explanation of all of them (there's already some text on 
the above, however I'll elaborate on the points you made).

-- Flemming

>  
> My 2 cents.
>
>  
>
>     ------------------------------------------------------------------------
>     *From:* Flemming Andreasen [mailto:[email-masked]]
>     *Sent:* Tuesday, June 26, 2007 08:36
>     *To:* Dan Wing
>     *Cc:* 'mmusic'
>     *Subject:* Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer
>
>
>
>     Dan Wing wrote:

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 26 Jun 2007 19:14:23 -0500

Francois Audet wrote: 

		The preconditions approach to me seems like the least
likely approach to be used in the real world.

		1.	
			You have to wait for the answer before playing
anything. For this to work, we'd effectively have to rely on provisional
responses including the SDP-answer (and not include the answer in the
200, since it would cause clipping). That in itself would be a change
for many SIP clients who never tought it necessary to provide an answer
before 200 before (at least, they didn't think they needed it).

	You'd have to include the answer in both the provisional
response and the 200, unless you use reliable provisional responses. 

Yes, agreed. Both cases are valid. 

		1.	
			Use the different payload type as per our kaplan
draft.

		My take is that option 1 is the more likely to have wide
support. But we should explain it a bit. 

		Option 2 is interesting, in a geeky way, and probaly
better than pre-conditions. But if people can live with 1, it seems much
simpler.

 Excellent. Thanks.

---

From: "Belling, Thomas" <[email-masked]>
Date: Wed, 27 Jun 2007 13:12:02 +0200

Hi all,
 
in my understanding including an answer in an unreliable provisional response is not allowed by RFC 3261 even it you repeat the answer in the 200 OK, see top of page 79:
"If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE."
Note that this quotations speaks about "the" answer, and I read that as a requirement that there is only one answer.
 
Even if you might argue there is a bit of ambiguity in the quotation, I suspect that there may be interoperabilty issues with clients either not beeing prepared to handle the answer in an unreliable provisional response (e.g. if they do not support 100rel), or getting confused if obtaining the same answer both in a provisional response and the 200 OK.
 
So I would recommend that you use at least 100rel for option 1 - preconditions is not really related and indeed not required for this issue.
 
Regards, Thomas

---------------------------------- 
Dr. Thomas Belling 
Nokia Siemens Networks  GmbH & Co. KG.         

Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft/ Registered office: München (Munich) - Registergericht /Commercial register: München (Munich), HRA 88537 - WEEE-Reg.-No. DE 52984304. Persönlich haftende Gesellschafterin /General Partner: Nokia Siemens Networks Management GmbH - Geschäftsführer /Board of Directors: Christian Unterberger, Joachim Malterer, Roland Meinzer - Sitz der Gesellschaft / Registered office: München (Munich) - Registergericht /Commercial register: München (Munich), HRB 163416 

	From: Francois Audet [mailto:[email-masked]] 
	Sent: Wednesday, June 27, 2007 2:14 AM
	To: Flemming Andreasen
	Cc: mmusic; Dan Wing
	Subject: RE: [MMUSIC] SDPCapNeg Issue #5: Media before answer

		Francois Audet wrote: 

			The preconditions approach to me seems like the least likely approach to be used in the real world.

			1.	
				You have to wait for the answer before playing anything. For this to work, we'd effectively have to rely on provisional responses including the SDP-answer (and not include the answer in the 200, since it would cause clipping). That in itself would be a change for many SIP clients who never tought it necessary to provide an answer before 200 before (at least, they didn't think they needed it).

		You'd have to include the answer in both the provisional response and the 200, unless you use reliable provisional responses. 

			1.	

			My take is that option 1 is the more likely to have wide support. But we should explain it a bit. 

			Option 2 is interesting, in a geeky way, and probaly better than pre-conditions. But if people can live with 1, it seems much simpler.

	I'll include an explanation of all of them (there's already some text on the above, however I'll elaborate on the points you made). 
	
	 Excellent. Thanks.

---

From: "Belling, Thomas" <[email-masked]>
Date: Wed, 27 Jun 2007 12:36:44 +0200

Hi all,

 
 
Regards, Thomas

 

	 

		Francois Audet wrote: 

			1.	

			1.	

	
	 Excellent. Thanks.