Hi, I have some additional comments and proposals. |2.2. Rejection of an Offer | (snip) | final response is sent, then a 2xx response should be sent, with a | syntactically correct response. I think "session description" is more appropriate than "response". I propose the alternative text for the above-mentioned one. ------------------------------------------------------------------------ final response is sent, then a 2xx response should be sent, with a syntactically correct session description. ------------------------------------------------------------------------ |3.1.1. INVITE Request with SDP | (snip) | not completed yet and the UAC must not send a new offer until it | receives the same SDP in the first reliable response, which is the | real answer. After sending the SDP in F6, the UAS must prepare to | receive a new offer from the UAC with an UPDATE request or a PRACK | request. "first" is not necessary. and UAS may not support UPDATE in this case. I propose the alternative text for the above-mentioned one. ------------------------------------------------------------------------ not completed yet and the UAC must not send a new offer until it receives the same SDP in the reliable non-failure response, which is the real answer. After sending the SDP in F6, the UAS must prepare to receive a new offer from the UAC with a PRACK request or an UPDATE request if supporting it. ------------------------------------------------------------------------ |3.3. Offer/Answer Exchange in an Established Dialog | (snip) | needed. Otherwise, some 3pcc flows will break. I think it is necessary to clarify the reason why some 3pcc flows will break. At least there should be "See RFCxxxx Section xx". |5.2.3. Answering an Initial INVITE with Offer | (snip) | port number in the answer. The media lines that are accepted should | typically be those that would have been offered had the INVITE not | contained an offer, excluding those not offered. This is a matter of wording. I propose the alternative text for the above-mentioned one. ------------------------------------------------------------------------ port number in the answer. The media lines that are accepted should typically be the intersection of the offered ones and the willing ones if UAS was an offerer. ------------------------------------------------------------------------ |5.2.3. Answering an Initial INVITE with Offer | (snip) | support at this time. However there is little benefit to including | added types. about the "little benefit" I propose the alternative text for the above-mentioned one. ------------------------------------------------------------------------ support at this time. Therefore asymmetric media format is tentatively negotiated. However there is a problem that this negotiated status can not be refreshed by sending an offer in the opposite direction. And besides some implementations only support sending and receiving symmetric media format. ------------------------------------------------------------------------ |5.2.3. Answering an Initial INVITE with Offer adding at the end of the section. ------------------------------------------------------------------------ When UAS reject all media lines, it may not send the failure response. Alternatively it may send the reliable non-failure response including the all media line with a zero port. ------------------------------------------------------------------------ |5.2.4. Answering when the Initial INVITE had no Offer adding at the end of the section. ------------------------------------------------------------------------ Even when UAC reject all media lines, it can not reject signally the offer included in the reliable non-failure response. And then it must send a PRACK or an ACK request including the all media line with a zero port. Alternatively it may send a CANCEL or a BYE request to terminate the dialog. ------------------------------------------------------------------------ |5.2.5. Subsequent Offers and Answers | (snip) | NOTE: This may be impossible for a B2BUA to follow in some | cases (e.g. 3pcc transfer) if it does not terminate media. I think it is necessary to clarify the reason why some B2BUA can not follow. At least there should be "See RFCxxxx Section xx". |5.3. Hold and Resume of media | (snip) | forced to answer something else. Without this behavior it is | possible to get "stuck on hold" in some cases, especially when a | third-party call controller is involved. I think it is necessary to clarify the reason why some UA "stuck on hold". At least there should be "See RFCxxxx Section xx". |5.4. Behavior on receiving SDP with c=0.0.0.0 | (snip) | c=0.0.0.0 has | no special meaning for the direction attribute of the accepted stream | in the answer. I propose the alternative text for the above-mentioned one. ------------------------------------------------------------------------ There is no clear rule for "c=0.0.0.0" in the answer. But the offerer probably stop sending the RTP/RTCP toward the answerer. Because "0.0.0.0" is not an effective IP address. ------------------------------------------------------------------------ Regards, Shinji >I just submitted draft-ietf-sipping-sip-offeranswer-12.txt. > >It addresses comments received re -11 from Okumura Shinji, Brett Tate, >Gao Yang, and Keith Drage. > >Shinji had a number of comments regarding sections 4.1 and 4.2. I tried >to fit them in, not literally, but hopefully in spirit. I had better >luck with section 4.1. For 4.2 I disagree that 3311 forbids the sending >of an UPDATE while awaiting a prack. (It probably should have been, but >I don't see that it is.) Ultimately I couldn't figure out how to make >the comments on that section work. Modulo the parts I agreed with the >existing text has equivalent meaning, so I left it unchanged. > >Brett pointed out that Retry-After cannot be used with 491. I have >removed any suggestion that it should be. > >Gao wanted more emphasis on avoiding cases where it might be necessary >to fail a prack. I have reworded things to make that more explicit and >removed suggestions to use 491 as a response to prack. > >Keith objected to normative language in the suggestions that Gao made. I >have avoided using normative language. > >Please review this carefully - its always possible that subtle issues >could have crept in. > > Thanks, > Paul > >IETF I-D Submission Tool wrote: >> A new version of I-D, draft-ietf-sipping-sip-offeranswer-12.txt has been successfuly submitted by Paul Kyzivat and posted to >> the IETF repository. >> >> Filename: draft-ietf-sipping-sip-offeranswer >> Revision: 12 >> Title: SIP (Session Initiation Protocol) Usage of the Offer/Answer Model >> Creation_date: 2010-03-08 >> WG ID: sipping >> Number_of_pages: 22 >> >> Abstract: >> The Session Initiation Protocol (SIP) utilizes the offer/answer model >> to establish and update multimedia sessions using the Session >> Description Protocol (SDP). The description of the offer/answer >> model in SIP is dispersed across multiple RFCs. This document >> summarizes all the current usages of the offer/answer model in SIP >> communication. >> >> >> >> The IETF Secretariat. _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
