[On request, splitting my previous question in separate emails...] Greetings fellow SIPers! I've got a few questions regarding how I should interpret a few things in rfc3263, and related text in 3261.
=========== Question 4. =========== It concerns the text about retrying after fatal transport errors, using a "completely" new transaction: RFC 3263 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4.3 Details of RFC 2782 Process ...Failure also occurs if the transaction layer times out without ever having received any response, provisional or final .... If a failure occurs, the client SHOULD create a new request, which is identical to the previous, but has a different value of the Via branch ID than the previous (and therefore constitutes a new SIP transaction). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The text says the "this constitutes a new transaction", but nothing more, and I find that it leaves the question of restarting Timer C and Timer F/B up to interpretation. Should I restart Timer C and/or Timer B/F when I create this new txn? My first assumption would be not to, but the text says quite clearly that it "constitutes a new transaction", and a new txn has a new Timer F, as well as - - - - - RFC3261, Chapter 16.6 Request Forwarding, (bullet 11) Timer C MUST be set for each client transaction when an INVITE request is proxied. - - - - - ..which could imply that even Timer C should be restarted why you retry on the next available SRV-record after failure. But doing this naturally means that a non-INVITE that fails towards a destination with 3 usable SRV records, will take 3*64T1 to complete, whereas the previous hop times out after Timer F as always. So, when reading rfc4320/21 where they clearly *imply* that you should NOT restart these Timers, I just though I would see if I could get some confirmation on this interpretation. I'd be very interessted, and thankful for whatever feedback you folks can provide. Thanks in advanced Regards Taisto Qvist IP-Solutions AB _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
