Hi Elwyn, Paul has just revised the draft in order to address your comments (he sent a separate email about it). Could you please let us know whether the new revision of the draft can be progressed at this point?
Thanks, Gonzalo On 26/09/2013 2:00 PM, Paul E. Jones wrote: > If a B2BUA failed to pass a Session-ID, that's definitely a problem if > that same device claims to support INSIPID. I'm not sure we need a > requirement for that, though, since being selective or inconsistent > would violate REQ3. > > Paul > > ------ Original Message ------ > From: "DRAGE, Keith (Keith)" <[email protected]> > To: "Paul E. Jones" <[email protected]>; "Elwyn Davies" > <[email protected]> > Cc: "General Area Review Team" <[email protected]>; > "[email protected]" > <[email protected]> > Sent: 9/26/2013 5:42:10 AM > Subject: RE: Gen-art LC review of > draft-ietf-insipid-session-id-reqts-08.txt >> 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
