Subject: Re: [MMUSIC] Revised ice-updated-offer draft

From: Randell Jesup <[email-masked]>
Date: Fri, 01 Jul 2011 23:49:16 -0400

On 6/30/2011 3:51 AM, Elwell, John wrote:
> I received no comments on -01. To prepare for a meaningful discussion in Quebec, it would be good to start that discussion now, on the list. In particular, the Conclusions section ends with the statement:
> " According to discussions in section Section 4, it seems to be the
>     case that the updated offer is needed, in practice, in very few
>     environments, and therefore consideration should be given to relaxing
>     the requirement in [RFC5245]."
> What would be people's reactions to updating RFC 5245 to relax this requirement?
>
> John
>

One comment on the draft:

      Switching codec or switching from audio to image requires an SDP offer-answer cycle.

Maybe, yes, but switching codecs from compressed to uncompressed may or may not
require a re-invite:

I.e. with this re-invite isn't needed for the codec change:

m=audio 3456 RTP/AVP 18 0
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000

Of course, if you don't specify both (why not?), that won't work.  (If you support both
you should specify both and probably accept both, so this *should* be the norm for this usecase)

Switching to image could be a re-invite to add m=image or to make it active (and make m=audio
inactive or turn off audio via m=audio 0 RTP/AVP 0).  In theory you could have both "active"
but only send data on one, though that wouldn't be normal I believe.

-- 
Randell Jesup
[email-masked]

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 4 Jul 2011 18:33:10 +0200

Randell,

Yes, you are correct that if you specify two codecs to start with, as transmitter you can switch at will. However, if you want the peer endpoint also to switch the codec it transmits, would you not need to do an updated offer? So endpoint A detects fax and switches from G.729 to G.711, but wants endpoint B (which may not be in a position to detect the fax) also to switch from G.729 to G.711.

Anyway, certainly the draft could do with some clarification in this area.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randell Jesup
> Sent: 02 July 2011 04:49
> To: [email-masked]
> Subject: Re: [MMUSIC] Revised ice-updated-offer draft
> 
> > I received no comments on -01. To prepare for a meaningful 
> discussion in Quebec, it would be good to start that 
> discussion now, on the list. In particular, the Conclusions 
> section ends with the statement:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 04 Jul 2011 23:24:06 -0400

> Yes, you are correct that if you specify two codecs to start with, as transmitter you can switch at will. However, if you want the peer endpoint also to switch the codec it transmits, would you not…

Ok, it's true that's undefined (though many endpoints will try to or 
must send the same codec they receive, and so would switch if you 
switch).  The only way to force a codec is to offer only 1 - and that 
causes problems if the other side doesn't support it, plus it makes 
switching impossible or only by reinvite.

That's a more general problem, however.  If you assume a single codec or 
the need to force the other side to switch, then yes, a reinvite is needed.

-- 
Randell Jesup
[email-masked]