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
