Hi Robert, Thanks for your report! This is at least something I've been missing from previous SIPits.
I have a comment ([CHH]) about the request merge issue: >-The merge detection language covers initial requests, but > not in-dialog requests. We don't expect in-dialog requests > to diverge and merge, but there are edge cases where it > can happen (such as through NAPTR/SRV failover). This became > particularly important when elements "optimized" failover, > shorting over to the next SRV record after 4 seconds of no > response instead of waiting for a full transaction timeout. [CHH] Unless I'm wrong, one of the main reasons we added the Via branch as a transaction identifier was to speed up and simplify. Now, with the current merge check, you still have to do parts of the "RFC2543 way", ie checking From tag, CSeq and Call-Id, PLUS that you have to check the Via branch. Now, if that check would have to be done for every request I think we need to re-consider the whole transaction identifier thing, because it will make the procedures more complicated and time-consuming than they were in RFC2543, I think. We would actually do the transaction identification according to RFC2543, and the checking of the Via branch would basically be an added part to that identifier. Comments? Regards, Christer Holmberg Ericsson Finland This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
