I agree. There seems to be an inconsistency between the statement below from 17.2.1 and Figure 7, which indicates that only 101-199 are handled by server transaction in "Proceeding" state.
"The TU passes any number of *provisional responses* to the server transaction. So long as the server transaction is in the "Proceeding" state, each of these MUST be passed to the transport layer for transmission" -Ramakrishna -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeroen van Bemmel Sent: Friday, October 14, 2005 12:07 PM To: Paul Kyzivat; Martin Koenig Cc: [email protected] Subject: Re: [Sip-implementors] 100 trying Paul, I found several things in RFC3261 that made me wonder as well: - INVITE server transaction (Figure 7): responses 101-199 from TU are to be sent, what happens to 100? - What happens if a retransmitted INVITE arrives within 200ms and the application has not yet sent a 100? I think an application (TU) should not send a 100 trying twice. What could happen, is that 100 is the last response sent, so when a retransmitted INVITE arrives the 100 is repeated. A reason for sending multiple 100 trying could be to account for packet loss on an unreliable transport. However, it's probably better to rely on the sender to retransmit its INVITE for this purpose. So IMO an application SHOULD NOT send more than one 100 trying Regards, Jeroen ----- Original Message ----- From: "Paul Kyzivat" <[EMAIL PROTECTED]> To: "Martin Koenig" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Friday, October 14, 2005 12:30 AM Subject: Re: [Sip-implementors] 100 trying > Why would you think it is *not* ok? > > Paul > > Martin Koenig wrote: >> Hello all, >> >> is it legal per RFC3261 to send two separate "100 trying" provisional >> responses for a SIP Request? >> >> A B >> INVITE ------> >> <----- 100 trying >> <----- 100 trying >> <----- (180 ringing) >> <----- 200 ok >> etc. >> >> A B >> REGISTER ------> >> <------ 100 trying >> <------ 100 trying >> <------ 200 ok >> etc. >> >> With best regards, >> Martin >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
