I don't know whether it is worth mentioning that while the action of the existing B2BUAs is not determinate, we do expect it to be consistent, i.e. it would not pass on the header field on one request, and fail to pass it on on another. Therefore session identifiers in that have been created at the start of a dialog based on being passed through should continue to work for the rest of the dialog, or other related dialogs.
Regards Keith > -----Original Message----- > From: Paul E. Jones [mailto:[email protected]] > Sent: 26 September 2013 04:04 > To: Elwyn Davies > Cc: General Area Review Team; draft-ietf-insipid-session-id- > [email protected] > Subject: Re: Gen-art LC review of draft-ietf-insipid-session-id-reqts- > 08.txt > > Elwyn, > > Please see my comments below: > > ------ Original Message ------ > From: "Elwyn Davies" <[email protected]> > To: "Paul E. Jones" <[email protected]> > Cc: "General Area Review Team" <[email protected]>; > [email protected] > Sent: 9/25/2013 6:47:50 PM > Subject: Re: Gen-art LC review of > draft-ietf-insipid-session-id-reqts-08.txt > >Hi, Paul. > >[Resend to all addressees] > > > >We seem to be converging... > > > >On Wed, 2013-09-25 at 22:22 +0000, Paul E. Jones wrote: > >> Elwyn, > >> > >> Comments below: > >> > >> > >Minor issues: > >> >> >s4.3: I am not clear whether there needs to be any special > >> >> >consideration > >> >> >if the B2BUA doesn't support Session-ID. There could be a number > >of > >> >> >other cases to consider. In particular whether the B2BUA would > >> >>forward > >> >> >the Session-ID if it didn't understand it. Does this also affect > >> >> >SBCs? > >> >> > >> >> There will be special considerations for B2BUAs. REQ3 requires > >B2BUAs > >> >> to pass it unchanged. Of course, there is the possibility that > >> >>existing > >> >> devices will not; we cannot change that. However, devices > >compliant > >> >> with the spec should. The intent is that the solution document > >will > >> >> spell out what B2BUAs should do when they receive a Session-ID > >and > >> >>when > >> >> they do not. This will be fully covered in the solution > >specification > >> >> currently being progressed. > >> >Right.. Not being a deep SIP expert, I was not sure if a legacy > >>B2BUA > >> >would pass through a Session-ID added by a non-legacy UA (say, A) > >when > >> >it created the call to B, which might or might not be legacy. If it > >> >didn't, does it matter or does it give rise to any requirements? > >> >Presumably the legacy B2BUA would reflect the Session-ID - or if not > >A > >> >shouldn't complain if it doesn't come back > >> > >> What a deployed SBC will do varies. Some might pass the header value > >> through and some might not. We already know that some definitely > >would > >> not. > >OK.. that is what I suspected would be the case. > > > >It doesn't answer the question as to whether the SBC would always > >reflect the SID back to A, and if it didn't might A get upset. And > >hence is it a requirement that A should bite its lip rather than > >complaining if the SID doesn't come back? > > What the group has requested is that INSIPID-aware SBCs would pass any > Session-ID header value through unmodified. However, aside from passing > it through, no other action is required of SBCs. > > We will, however, allow an SBC to fabricate a value on behalf of a User > Agent that is not an INSIPID User Agent. The reason for this is to > allow inspection of call logs throughout a domain, for example. Imagine > a service provider edge where a customer's phone does not generate a > Session-ID, but the service provider wants one for use inside their > network. > > In any case, the Session-ID is intended to be end-to-end. It originates > at each user agent and SBCs (or B2BUAs in general) just mindlessly > passing it along. If an endpoint does not receive it (or if it does not > traverse all nodes in the path), it only means we lose the ability to do > diagnostics, logging, signaling correlation, etc. using that value. > > Paul _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
