On Fri, Dec 18, 2009 at 9:14 AM, M. Ranganathan <[email protected]> wrote: > Hello, > > I am building a sip tester where I determine relatedness ( or more > precisely, causality) between a sent and received message so that the > tester can only simulate activity between endpoints of interest. I can > use Via for determining causality between sent and received endpoints > when there are no intervening B2BUA. Unfortunately, that this does not > work when you have an intervening B2BUA. > > To see this, consider a UAC sending an INVITE through a B2BUA that > re-originates the INVITE using a different Call-ID.
And further it does not preserve the Via headers of the inbound Client Transaction as it re-originates the request. How do you > connect the UAC (Client Transaction) that sent the request with the > UAS (Server Transaction) that got and processed the request? > > For this, the References header comes in handy. However, there is > still a problem in that it does not disambiguate between two fork > targets to the same endpoint ( they will both have the same call ID). > Second, call-ID alone is not enough to distinguish between two such > B2BUA originated requests in close succession. It says nothing about > ordering if these belong to different Dialogs on on the UAS. For now, > this is not a problem because we do not have such a case. Call-ID > alone is enough to determine the server transaction of interest. > However, to make it truly general, I think we need to add a tag > parameter to the References header so that the B2BUA can compute such > a tag to relate a Server Transaction to a Client Transaction that was > causally connected to the inbound Server Transaction. > > Incidentally, here is another excellent reason to implement the > References draft -- it allows one to build testable components in the > presence of such nasties as B2BUAs. > > > Do we need such a tag? > > > Regards > > Ranga > -- > M. Ranganathan > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
