From: Paul Kyzivat <[EMAIL PROTECTED]> > A larger problem is that this added Session-Id is not observable from > the "input" side of the B2BUA, meaning that the correlation between > the incoming Call-Id and the Session-Id can only be reliably extracted > from the B2BUA itself, which obviates much of the value of Session-Id. > However, the B2BUA can create a 100 response to the request that > contains the Session-Id header and can send it to the upstream > element. This makes the added Session-Id manifest to any network > logging.
Since 100 is hop by hop, that response will only be seen by the prior node. I'm not seeing the value in this. Even if it were a 1xx that went all the way back to the UAC, the nodes that would get to see it would by definition be ones that don't understand it and so will not use it for anything. True, but I'm addressing a requirement that I haven't stated: Enabling an "outside observer" to correlate network traces on the various networks. In practice, what you need is for the messages, as captured in network traces, to carry enough information that you can tell which messages are part of the same (logical) dialog. The Session-Id provides this information very nicely, as long as an introducing middlebox-element emits some message on the input side that reveals the input-side Call-Id with the Session-Id. Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
