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. If a deployed SBC does not pass the header through unmodified,
then it "breaks" the end-to-end identifier. We know that and it is one
of the reasons for doing this work. We want something that could be
used end-to-end if domain owners will allow it. Other values are not
necessarily safe to use end-to-end (e.g., they might leak personal
data).
>
>Nits/editorial comments:
>s1: The purpose of the document is not explicitly set out in s1 -
>although of course it is clear in the abstract. s1 should contain a
>near copy of the abstract which also states that the document
proposes
>requirements for a new SIP header (I assume) called "Session-ID".
You're right. I struggled with placement. Finally, I decided that it
sounds best as the last paragraph of Section 1 (just copying the
entire
abstract). Sound OK?
I could mention "Session-ID" as the name of the header, but this
actually could be dangerous. At present, we're struggling with
interworking with an already-existing (and implemented) I-D that uses
"Session-ID". We hope to re-use the same header and provide
interworking with that draft. However, if we find we cannot, we may
want to select a different header name.
Your problem here is that Session-ID is used explicitly in the rest of
the document (starting with the title of Section 3 ;-) ). So I guess
you have to find some form of weasel words like 'tentatively named
"Session-ID"' or '(NSIDIH - new session id identifying header)' and use
NSIDIH instead in the rest of the doc.
<<snip>>
I can fix this rather easily. I'll change "Session-ID" to "session
identifier". In no place are we explicitly referring to the header
itself, but just the "identifier".
>s3.2, Figure 1: [very nitty] Might be desirable to indicate the
>existence of the middlebox(es) on the message arrows
>(e.g., .....()..... or some such). Also label A and B as user
agents.
I changed it to show "UA-A" and "UA-B". I'm not sure what to put in
the
lines going left/right to showcase a B2BUA. Something like this?
UA-A UA-B
SIP message(s) ------- [ B2BUAs ] --------> SIP message(s)
SIP message(s) <------ [ B2BUAs ] --------- SIP message(s)
I'm not sure that's more readable. What did you have in mind?
Maybe just...
UA-A B2BUAs UA-B
SIP message(s) ------- [] --- [] ---------> SIP message(s)
SIP message(s) <------ [] --- [] ---------- SIP message(s)
OK, done.
>s4.1: Acronyms UA, B2BUA and SBC need expansion (UA and B2BUA are
>effectively used in s1. SBC may need a reference (RFC 6135?)
Did you mean RFC 5853?
Looking at it probably yes!
I was (mindlessly) going on the ref in the RFC Editor's abbreviation
expansion list -
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
They probably ought to be told this is not the best ref.
<<snip>>
OK, I'll insert an informative reference to that spec.
Paul
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
