[EMAIL PROTECTED] wrote:
In regard to adding a Session-Id to requests are not given one by the
UAC:
A B2BUA can add one, of course. But a proxy can also add a header to
a request, and can remain strictly RFC 3261 compliant while doing so.
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.
Specifically, *subsequent* requests in the same dialog won't carry the
same value, at least until the node that inserted the value is reached,
if it is reached. And even then the same value won't be inserted unless
the inserting node is dialog stateful. That argues for only having
dialog stateful elements insert the header.
Ultimately, for it to be useful, the node that wants to make a reference
must be aware of the value. AFAIK that is usually the UAC.
Which leads to the question of whether we want to include Session-Id
in responses as a matter of course (as we do Call-Id).
Also, given the intended ubiquity of Session-Id, a one-letter
abbreviated header name should be defined.
:-)
Paul
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
_______________________________________________
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
