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

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

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