Re: [Insipid] Pre-WGLC INSIPID Session-ID Review Comments

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

Christer,

Thanks for the feedback.  I'll try to address each point:


>General:
>-----------
>
>- The document claims that the Session-ID is true end-to-end, because 
>it will not be modified by intermediaries. But, there is no text on how 
>that is achieved. Obviously, we cannot guarantee that it won't happen 
>(even if there is "MUST NOT" wording), but I think you need to have 
>some text which talks about the reasons why Call-IDs are modified, and 
>why those reasons don't apply to the Session-ID.

In the introduction, we specify two examples of why the current Call-ID 
values are not suitable, including the fact that SBCs change the values 
as they go through.  We also mention protocol interworking as an issue.

I'm not sure what we can write into the document to ensure that devices 
do not change the Session-ID.  It's certainly possible, just as the 
Call-ID is changed.  However, changing the session ID would mean the 
device is not compliant with the specification.  That could happen on 
purpose (violating the spec) or it could happen because there is an 
older device that does not know the header and simply discards it.  
That's certainly true of any new protocol element one might introduce.  
If you think we should say something explicit about this, where should 
we say it and how should we phrase it?


>- The document talks about interoperability with H.323, but nowhere is 
>there any text showing that both protocols now use the same format for 
>the session id.

That is true, though RFC 7602 (requirements) mentions that a parallel 
effort is taking place in SG16.  In fact, here's the draft text: 
http://ftp3.itu.int/av-arch/avc-site/2013-2016/1406_Sap/Draft-H.460.SessionID.zip.

That text was accepted as the baseline text for an extension to H.323.  
However, it's not something we can reference right now.  Do you feel we 
should re-state the fact that the ITU is undertaking the same work for 
H.323, or do you think leaving that fact in the requirements document is 
enough?

>Section 5:
>-------------
>
>I suggest to re-name the section name to "SIP Session-ID Header Field"
>
>You need to split the text into subsections.
>
>Something like:
>
>5.1 General
>5.2 Syntax
>5.3 UA Behavior
>5.3.1 UAC Behavior
>5.3.2 UAS Behavior
>5.4 Proxy Behavior
>5.5 B2BUA Behavior

I think renaming this is a good idea.  Given the whole document is about 
SIP, I think we can get rid of that, too.  I think "The Session-ID 
Header Field" would be sufficient.

However, I think making the structural changes is probably unnecessary.  
Splitting UAS and UAC behavior, for example, will result in a lot of 
redundant text.   The same is said of a SIP proxy or B2BUA.  Both are 
intermediaries and should operate in the same way. We considered that 
arrangement before, but felt it was simpler to just describe endpoint 
behavior and intermediary behavior as we have it.

>Section 6:
>-------------
>
>The text in this section should go into UA Behavior.
>
>Section 7:
>-------------
>
>The text in this section should go into Proxy Behavior and B2BUA 
>Behavior.
>
>
>I do have more comments on section 6 and 7, but I'd like to see the 
>restructuring (as suggested in my comment on section 5) before giving 
>those, because some may go away.
OK, let's talk about those.  I just submitted -08 with a few minor 
changes.

Paul