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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.