Should there be one more change to 3261 for invfix? Section 14.1 para 6 point # 2 should include the Accepted state?
"If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed, *accepted* or terminated state before initiating the new INVITE" Thanks Nasir Khan BEA Systems Inc. On 7/17/07, Robert Sparks <[EMAIL PROTECTED]> wrote:
On Jul 17, 2007, at 1:42 AM, Nasir Khan wrote: Hi Robert, I have 3 comments / suggestions w.r.t this ID. Comment-1 ---------------- Should there be any change with respect to receiving CANCEL in Accepted state? Hitherto the UAC was getting a 481/CANCEL in such cases. Now we will get 200/CANCEL with no effect on IST. The reason for this question is backwards compatibility, however I can myself argue both ways on this one. What do you think? I don't see any issue here. The UAC already has to be prepared for either response. Comment-2 ----------------- In section 6.7 of the ID about the Timer-L you say - "and the amount of time this (or any downstream) UAS core might be retransmitting the 2xx while waiting for an ACK. " How does 2xx retransmission timer affect the choice of Timer L? Comment-3 ----------------- Shouldnt the Timer L be set to T4 which represents the amount of time the network will take to clear messages between client and server transactions? Since 2xx is sent reliably anyway, IMHO we do not need to link Timer L to Timer B. For both of these comments - Timer L is keeping the transaction in place while the TU on top of this server transaction finishes its job of retrasmitting 200s until it gets an ACK. It's not just clearing messages that are already in the network. Remember that those 200s might get lost, and timers on the UAC's side will cause the INVITE request to be retransmitted. This Timer makes sure the server transaction is still there to receive that retransmitted INVITE. Does this clear up the questions you had? Thanks Nasir Khan BEA Systems Inc. On 6/27/07, Robert Sparks <[EMAIL PROTECTED]> wrote: > > Everyone - > > I've put together a proposal for addressing the spec bug captured at > http://bugs.sipit.net/show_bug.cgi?id=769 > > Please read through > http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt > and comment. > > RjS > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > -- Discuss SIP Servlets at http://groups.google.com/group/sipservlets/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
-- Discuss SIP Servlets at http://groups.google.com/group/sipservlets/
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
