Re: [Gen-art] Gen-art LC review of draft-ietf-insipid-session-id-reqts-08.txt

["Paul E. Jones" <[e-mail]>]

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)" <[e-mail]>
To: "Paul E. Jones" <[e-mail]>; "Elwyn Davies" 
<[e-mail]>
Cc: "General Area Review Team" <[e-mail]>; 
"[e-mail]" 
<[e-mail]>
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:[e-mail]]
>>  Sent: 26 September 2013 04:04
>>  To: Elwyn Davies
>>  Cc: General Area Review Team; draft-ietf-insipid-session-id-
>>  [e-mail]
>>  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" <[e-mail]>
>>  To: "Paul E. Jones" <[e-mail]>
>>  Cc: "General Area Review Team" <[e-mail]>;
>>  [e-mail]
>>  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
>