Re: [Insipid] draft-ietf-insipid-session-id-15: comments and questions

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

Brett,

>Section 2 paragraph 3: I'm not confident that I'm interpreting the
>paragraph correctly.  If during call setup a device that typically acts 
>as
>a proxy or B2BUA rejects the INVITE with a failure responses (such as 
>407,
>422, 403, 421, 400, et cetera) instead of relaying the request, should 
>it
>follow section 6 or section 7?  For instance within RFC 3665 section 
>3.2
>F2, should the proxy follow section 6 or section 7 when sending the 407
>response?  It was the final hop for the request (and Alice might not 
>try
>again with Proxy-Authorization); however I'm not sure if this
>paragraph/draft classifies the proxy as an endpoint within this 
>situation.
>My current interpretation is that the proxy follows section 7.

I'm not sure which section you're referring to (but I'm sure it wasn't 
the terminology section).

If a proxy rejects an INVITE with 407, it would follow Section 7 since 
it is not an endpoint.  It has a few choices.  If it does not implement 
this spec, it just returns 407 without a Session-ID header.  If it 
implements this spec, it would return {N,A}.  And it's finished.   It 
may then clear state (aside from holding onto the message to respond to 
retries.)


>  Section 2 paragraph 3: If it matters, there are devices which can 
>behave
>as both endpoints and intermediaries from the perspective of this
>paragraph/draft.  There are situations where a request will need to be
>processed without complete information to know if section 6 or section 
>7
>should apply.  This can occur when receive a request for unknown 
>dialog.
>I guess that the implementer will decide if better to follow section 6 
>or
>section 7 within such situations.

Yeah, I don't know.  If it's acting like an endpoint, then it should 
behave as one.  Otherwise, it sounds like it might be like a 3PCC 
device, which we also cover.  That's one example that acts like both.  I 
guess it's useful to think about the intent of the spec in spirit, which 
is to convey an end-to-end identifier primarily for the purposes of 
diagnostics.  One should not run billing of of this, but there should be 
an aim to ensure the right values are there to help track problems with 
calls.


>Section 5 paragraph 6: Concerning "that send provisional responses" 
>within
>the last sentence, "provisional" can be removed (or become "provisional
>and other") since not limited to provisional responses.

Correct.  I'll make that change.


>Section 6 paragraph 4: Within sentence 1, 5xx is potentially missing 
>from
>"3xx and 4xx" discussion.

Actually, I question why we put 4xx there.  The whole point of that text 
is to deal with redirection or initiation of a subsequent call after the 
first call failed.  I think we should remove 4xx from that paragraph.  
UUIDs are still maintained betwen INVITE/4xx/INVITE, but that is not 
what that paragraph is about.


>Section 7 paragraph 4: You might want to explicitly exclude 2xx from 
>the
>mandate.  For instance, it looks like the current wording could
>potentially apply to "disaggregated media" which was a topic discussed 
>in
>March 2013.

You're talking about the aggregated response section?  I think we need 
to leave 2xx out of that.  I'm not sure how disagregated media fits into 
that.


>Section 7 paragraph 5: What is the relationship of paragraph 5 to
>paragraphs 6 and 7?  For instance, does the MUST within paragraph 5 
>cause
>MAY within paragraphs 6 and 7 to become MUST for such transferring
>intermediaries?

Paragraph 5 places a requirement on PBXes -- that's the main focus.  If 
they transfer a call, they need to properly convey Session-ID headers.

Paragraph 6 is totally unrelated.  If an SBC gets an INVITE from an 
endpoint without a Session-ID header, it *may* fabricate one for the 
endpoint.  It's not obligated.  If it does, then it needs to 
consistently convey it.

Paragraph  7 appears to be redundant with paragraph 6, but it has 
language about  the B2BUA acting like an endpoint.  Let me work to merge 
these two.


>
>Section 7 paragraph 9: "of am endpoint" should be "of an endpoint".

Thanks!


>
>Section 7 paragraph 10" "previous two paragraph" should be "previous 
>two
>paragraphs".

Thanks!


I'll try to get a new draft out before the deadline.

Paul