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/
|
