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

[Christer Holmberg <[e-mail]>]

Hi Paul,

Comments inline.

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

Sure, but how does that ensure that SBCs won't do the same for the Session-ID? 

> We also mention protocol interworking as an issue.

Sure. But, as I said below, the document doesn't show that. But, more on that below.

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

You could say that about lots of things, but that doesn't prevent SBCs to do "non-compliant" things :)

You need to give people technical reasons why they reasons they modify Call-ID don't apply to Session-ID. "Because the draft says so" is not such reason :)

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

For example, one reason is that, traditionally, the Call-ID often contains the IP address of the endpoint, which is not the case for Session-ID. So, there is no need for the SBC to modify the Session-ID for privacy reasons.

Another example is that the Call-ID is part of the SIP session identifier, which is not the case for Session-ID. So, even if people want to use different SIP sessions on each side of an SBC, that does not require a change to Session-ID.

Hadriel have had a number of reasons, so if he is still following this work then he can perhaps give more input.

---------------

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

IF we are going to talk about H.323, and interoperability, we have to show it.

And, we can always finalize the other parts of the draft, and move it to the RFC editor's queue, where it will be held while waiting for the ITU work to finalize.

When do you think ITU will have something we can reference? 

---------------


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

Agree.

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

Such text should go into a "General" section.

E.g.

5.3 UA Behavior
5.3.1 General
5.3.2 UAC Behavior
5.3.3 UAS Behavior
---

>The same is said of a SIP proxy or B2BUA.  Both are intermediaries and should operate in the same way. 

Is that really true? What about the PBX case where you have an endpoint joining sessions together etc?

> We considered that arrangement before, but felt it was simpler to just describe endpoint behavior and intermediary behavior as we have it.

Then you should call the section "Proxy Behavior". "Intermediary" is a very confusing word.


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

I'll take a look later :)

Regards,

Christer