Re: FW: I-D Action:draft-kaplan-sip-session-id-00.txt
Paul Kyzivat <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
[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