Thomas, That looks good to me. Thanks!
Brian On 2009-02-13 03:37, Thomas Schierl wrote: > Hi Brian, > > we think that such a modification in section 6.1 makes sense: > > Please find a possible modification of the text below: > > > original text: > In the first case, if the original sender of the offer still wishes > to establish communications, it SHOULD generate a new offer with a > single media stream that represents an Operation Point. Note: in > most cases, this will be the base layer of a layered Media Bitstream, > equally possible are Operation Points containing a set of enhancement > layers as long as all are part of a single media stream. In the > second case, if the sender of the offer still wishes to establish the > session, it SHOULD re-try the request with an offer including only a > single media stream. > > new text: > In the *case (1)*, if the original sender of the offer still wishes > to establish communications, it SHOULD generate a new offer with a > single media stream that represents an Operation Point. Note: in > most cases, this will be the base layer of a layered Media Bitstream, > equally possible are Operation Points containing a set of enhancement > layers as long as all are part of a single media stream. * > In case (2), if the sender of the original offer has identified that the > refusal > to the request > is caused by the use of DDP grouping, and* > if the sender still wishes to establish the > session, it SHOULD re-try the request with an offer including only a > single media stream. > > > > Best regards, > Thomas > > Brian E Carpenter wrote: >> Thomas, >> >> On 2009-02-06 02:14, Thomas Schierl wrote: >> >>> Hi Brian, >>> >>> Brian E Carpenter wrote: >>> >>>> Hi Thomas, >>>> >>>> On 2009-02-04 22:24, Thomas Schierl wrote: >>>> >>>> >>>>> Dear Brian, all, >>>>> >>>>> Brian, thanks a lot for carrying out the review! >>>>> >>>>> Here are our replies: >>>>> >>>>> 1. We do not think that it is required for the offerer to find out, why >>>>> the offer has been rejected. At least we do not know any context where >>>>> the reason for rejecting an offer is indicated. >>>>> >>>>> >>>> Maybe I should be more precise about my question. You say that when the >>>> sender receives: >>>> >>>> >>>> >>>>>> (2) with a refusal to the request (e.g., 488 >>>>>> Not acceptable here or 606 Not acceptable in SIP). >>>>>> >>>>>> >>>> then >>>> >>>> >>>> >>>>>> In the >>>>>> second case, if the sender of the offer still wishes to establish the >>>>>> session, it SHOULD re-try the request with an offer including only a >>>>>> single media stream. >>>>>> >>>>>> >>>> I don't understand how the sender decides that it is in this case >>>> rather than any other reason for receiving a Not acceptable reponse. >>>> Is it supposed to *guess* that the reason is the use of DDP? I don't >>>> know what IF statement I would need, if I was writing code for the >>>> sender. >>>> The problem would not arise if there was a specific "DDP Not acceptable" >>>> response. >>>> >>>> >>> Ok, I got it now. What would be an appropriate way forward here? >>> Removing the part "In the second case ..."? Or refining the language, >>> saying something like: if the sender has identified, that only "DDP" can >>> be the problem, then ... >>> >> >> Something like that. If I was implementing this, I guess I would end up >> with some logic like this: >> >> IF response=="Not acceptable" AND DDP_sent==TRUE >> THEN try again without DDP >> ELSE report failure >> >> My concern is that a junior programmer reading your document >> might not reach the correct solution without some extra words. >> >> Brian >> >> >>> Thanks, >>> Thomas >>> >>>> >>>> >>>>> 2. "Aforementioned" can be removed in RFC editor processing (AUTH48), or >>>>> IESG note. >>>>> >>>>> >>>> Thanks >>>> >>>> >>>>> 3. DDP and RDMA in the RFC4296 sense are about as far away technically >>>>> than it gets from SDP signaling. Confusion is, in our opinion, >>>>> unlikely. Can we ask the MMUSIC chairs and Cullen for guidance here? >>>>> >>>>> >>>> Sure. I have no strong feeling about this. >>>> >>>> Regards >>>> Brian >>>> >>>> >>>>> Best regards, >>>>> Thomas >>>>> >>>>> >>>>> >>>> >>>> >> >> >> > > -- > Thomas Schierl > -------------- > Fraunhofer HHI > > > > > > > ---- > Visit us at > > GSM mobile WORLD CONGRESS / Barcelona, Spain / 16-19 February 2009 / Hall 1 > Booth 1G49 > http://www.mobileworldcongress.com/ > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
