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