Hi Paul,
>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.
Thank you for your work.
> 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.)
A B
| |
| INV (offer0)|
|<------------------------------|
| |
| 1xx-rel (answer0) |
|------------------------------>| --+
| | | Acknowledge
| offer1(UPD) offer2(PRA)| |
|============\ /===============| <-+
| \/ |
| /\ |
|<===========/ \==============>|
| |
[OS]>I think that the offer1 is a protocol violation as PRACK case in 4.1.
[OS]>Probably RFC3311(UPDATE) prohibits this operation.
RFC3311/Page 5
and for the callee:
o If the UPDATE is being sent before the completion of the INVITE
transaction, and the initial INVITE contained an offer, the
UPDATE cannot be sent with an offer unless the callee has
generated an answer in a reliable provisional response, has
received a PRACK for that reliable provisional response, has
not received any requests (PRACK or UPDATE) with offers that it
has not answered, and has not sent any UPDATE requests
containing offers that have not been answered.
At the time of sending the UPDATE, UA A(callee) has NOT received
a PRACK for that reliable provisional response. According to the
above description, the UPDATE cannot be sent with an offer.
Regards,
Shinji
> 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
