> If the INVITE was Routed through > another set of proxies (for example, > if it had a Route header) and the > ACK is now directly sent to the UAS > the top via header of the ACK will > be different from the top via header > of the original INVITE received at > the UAS (but the first via header > of the invite will, however match) > so how do we find the server > transaction corresponding to the ACK? > Should I look at the first via header > when record routing is not enabled > and last via header when record routing > is enabled ? Will this always work?
No. It would likely get confused during situations with multiple proxies when the last did not record-route. For matching ACK to response, the ACK's via is typically only useful during transaction matching associated with having sent a 2xx and negative responses for INVITE's with same CSeq within an already established dialog. In such situations, the top via for the negative responses will match the corresponding ACK's via. By default, the ACK with the non matching via corresponds to the 2xx in such situations. Such actions are potentially broken with older proxies; however it should work for RFC 3261 proxies. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
