Re: [Sipping] sipping-sip-offeranswer-05: comments and questions

["Brett Tate" <[e-mail]>]

I agree with Paul concerning Christer's proposed text.  The text is
accurate; but the additional proposal does not appear to be a workable
solution.

I prefer PRACK 488 be discussed within the draft separately from
Christer's proposed solution.  This would potentially impact sections
2.2, 3.2, 4.1, and/or 6.1.  As suggested by Paul within a prior email,
the text would be based upon the resolution of the careful analysis of
rfc3262.  As mention earlier, my analysis is that the UAC should act
upon the PRACK 488 and resend the PRACK with higher cseq and appropriate
SDP adjustments (or no SDP).  I'll read rfc3262 again; and I assume Paul
and Christer will do the same.

Based upon my re-reading of rfc3262, I'll send a follow-up email later
today or tomorrow.

Thanks,
Brett

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]] 
> Sent: Monday, February 18, 2008 10:03 AM
> To: Takuya Sawada
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; Brett Tate
> Subject: Re: [Sipping] sipping-sip-offeranswer-05: comments 
> and questions
> 
> I agree that the proposed addition is accurate in that it 
> does indeed describe something that was proposed. So I don't 
> have any great objection to including this statement.
> 
> That doesn't mean I agree such a solution is workable.
> 
> 	Thanks,
> 	Paul
> 
> Takuya Sawada wrote:
> > Hi,
> > 
> >> Takuya,
> >>
> >> If this change can be agreed quickly, let's go ahead and make it 
> >> prior to
> > forwarding to Jon/IESG (currently targetted for March) - 
> that way we 
> > don't have a repeat of this discussion during IETF LC.
> >> So, anyone else that might have feedback on this proposed text, 
> >> please comment
> > ASAP. 
> > 
> > I haven't heard any comments on Christer's proposal so far.
> > If no one speaks up today (Monday) in US time, can I modify the 
> > document as proposed and submit it?
> > 
> > Then, do we need new version (-06)?
> > 
> > Regards,
> > Takuya
> > 
> >> Thanks,
> >> Mary. 
> >>
> >> -----Original Message-----
> >> From: Takuya Sawada [mailto:[e-mail]]
> >> Sent: Friday, February 15, 2008 5:01 AM
> >> To: [e-mail]; [e-mail]; 
> >> [e-mail]
> >> Cc: [e-mail]; Barnes, Mary (RICH2:AR00); 
> [e-mail]
> >> Subject: Re: [Sipping] sipping-sip-offeranswer-05: comments and 
> >> questions
> >>
> >> Hi,
> >>
> >> I think the proposed text can be added if all can agree.
> >> It is just to add another idea which was proposed in the 
> recent discussion. 
> > Several ideas have already been there reflected from the 
> similar type 
> > of discussion in the past.
> >> I think it is not a big change.
> >>
> >> There may be a matter of timing. How do you think?
> >>
> >> Regards,
> >> Takuya
> >>
> >>> Hi,
> >>>
> >>> Below is some proposed text (starting with "It was also 
> proposed...").
> >>>
> >>>
> >>>
> >>> 6.1. Rejecting PRACK Offer
> >>>
> >>>   As stated in section 2.2. and 3.2. , it is recommended that an 
> >>>   offer not be sent in a PRACK request unless UAC has 
> strong reasons 
> >>>   to assume the receiver will accept it. Even so, there 
> may be cases 
> >>>   when the UAS has to reject the offer for some reason. 
> The current 
> >>>   RFCs do not provide a way to reject the offer and at 
> the same time 
> >>>   to acknowledge the reliable response. 
> >>>
> >>>   Several ideas were presented to resolve this issue, 
> such as sending 
> >>>   2xx PRACK response without SDP to reject the offer, or 
> sending SDP 
> >>>   with a decreased version value in the o-line. It was 
> also propsed to allow non
> > -2xx responses to PRACK, in order to reject an SDP offer 
> carried in the PRACK.
> >  The 
> > response would still acknowledge the PRACK, and the UAS would cease 
> > transmission of 
> > the reliable provisional response acknowledged by the PRACK 
> request. Some of 
> > the 
> >>>   candidates may also be adapted as a way to reject an 
> unacceptable 
> >>>   offer in a response. Anyway, those proposals violate 
> the current 
> >>>   rules and lose backward compatibility to some extent 
> (e.g. section 
> >>>   5 of RFC 3262). It is beyond the scope of this document 
> and remains 
> >>>   for further study. 
> >>>
> >>>        NOTE: Deprecation of the usage of offer in PRACK may be 
> >>>        another solution. As the precondition mechanism 
> specification 
> >>>        [2] explicitly shows a usage of sending offer in 
> PRACK, its 
> >>>        deprecation could cause backward compatibility issues.   
_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP