-----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
