While youre at it, the INVITE server transaction could use some
rethinking. Terminating on a 2xx but on no other final response is a
bit daft and makes people like me want to cut corners rather than use
other objects such as the dialog or session to handle the ACK, which
doesn't really make for a nice logical model :) The ACK is attached to
a single transaction and should handled by that transaction (as it is
for a non-2xx final response).
Peter Hanratty
Senior Software Developer
Pinnacle Telecom Group PLC
Brooke House
4 The Lakes
Bedford Road
Northampton
NN4 7YD
Tel: 0845-006-0800
Fax: 0871-872-0866
On 08/04/2011 08:56, Iñaki Baz Castillo wrote:
2011/4/8 Dean Willis<[email protected]>:
I think you're right that the spec is written incorrectly. I believe it should
describe that the multiplier on T1 doubles with each reset. This is not clear in the
existing text. So for example, if 8*T1< T2, then the third reset is 8*T1, and if
16*T1< T2, then the 4th reset is 16*T2
Otherwise said, MIN(2^N*T1,T2) where N is the repetition iterator.
That would clarify it, right.
PS: Sorry for the cross-posting, I don't know which maillist is better
to report it.
[email protected] would probably be the right place.
Finally I've reported an errata for RFC 3261 (hope it's also a good place):
http://www.rfc-editor.org/errata_search.php?rfc=3261
Thanks a lot.
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.894 / Virus Database: 271.1.1/3545 - Release Date: 04/01/11
19:36:00
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use [email protected] for questions on how to develop a SIP
implementation.
Use [email protected] for new developments on the application of sip.
Use [email protected] for issues related to maintenance of the core SIP
specifications.
