Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-00

From: James Polk <[email-masked]>
Date: Wed, 03 Jul 2013 19:02:25 -0500

Robert

Can you pick out a call flow from an existing RFC or ID that you 
would like for me to add in a Session-ID to for each of the following messages:

- 100 Trying
- CANCEL and
- whatever other messages you would like to see in s9

Just give me the doc name and which figure in said doc you want me to 
include a Session-ID in that call flow, and I'll do it.

Thanks

James

At 09:25 AM 4/10/2013, Robert Sparks wrote:
>Thanks Paul -
>
>Trimming heavily to just a couple of things.
>
>On 4/10/13 1:43 AM, Paul E. Jones wrote:
>>
>>
>>PEJ: I got the point.  What you said is correct, which is why I 
>>used the language "sender of the message".  If that's not clear, 
>>how can we make it clear?
>Add a sentence that says something like this:
>
>"Note that unlike To and From tags which remain in the same order in 
>the request and all responses to the request, the components of the 
>Session-ID in each response will in the reversed order from the request".
>
>I'm sure that needs wordsmithing though.
>
>Now, for the martian value conversation, using this figure again, 
>but still trimming heavily:
>>
>>(Again, view in a fixed-width font)
>>Alice    Intermediary
>>   | S:{A}   |
>>   |-------->|
>>   | S:{B,A} |
>>   |<--------|
>>   |         | (the service interactions section 6 paragraph 3 mentions
>>   | S:{B,M} |  happen somewhere over here)
>>   |<--------|
>(leaving this bit for context)
>>You are saying that the next message alice sends in that session 
>>should contain S:{A,B}, and would never contain an M.
>>The document does not yet say that.
>>
>>PEJ: The text says Alice would never change her UUID for the 
>>duration of the session.  She would always send {A, <whatever she 
>>received in the most recent message>}.  If that's not clear, it 
>>should be simple to clarify it.  I'll admit I might be conveying 
>>something that's not written clearly, since I know what I 
>>expect.   But, I'm missing why it's not clear.  In the above flow, 
>>Alice received a message from B to her (A).
>Here's what I want to talk about.
>>Then she received a message from B to her, but this time 
>>mislabeled.  I don't see how that can happen.
>I think we're identifying then that the document needs to be clearer 
>when you move paragraph 3 of section 6.
>Right now, the document explicitly _says_ that figure can happen. 
>Look at the figure and this text. If the text is
>meant to say something that prevents (or at least does not imply) 
>that picture, call it out.
>
>    It should be noted that messages received by a UA might contain a
>    "remote" parameter that does match the UAs UUID.  This might happen
>    as a result of service interactions by intermediaries and MUST NOT be
>    regarded as an error.
>
>>Now, had B been transferred to C (using some non-standard 
>>signaling), C might send a message to A that was {C,M}.  Alice 
>>should accept that (as per Section 6).  But, I would not expect the above flow.
>So more explanation in the document about what could lead to the 
>condition is in order (providing an full example of the service
>interaction involved), and I think we need to dive a level of detail lower.
>
>Are you saying that inside a given SIP dialog, you know of no way 
>that Alice would receive a message with a Session-ID containing a 
>remote-uuid did not match what Alice had provided in an earlier uuid?
>
>If so, then the only time this could occur is in an out of dialog 
>message (like an initial INVITE). Are you sure that whatever 
>circumstances that led to there being a remote-uuid in that message 
>wouldn't also have lead to there being a non-empty to-tag? If it 
>did, Alice would reject the message with a 481. If you _can_ think 
>of a circumstance where Alice would get an initial message with a 
>populated remote-uuid that she didn't provide that was otherwise 
>admissible SIP, could you put a description of it in the document?
>
>Either way, in the text you are working on re: not using the 
>remote-uuid, please explicitly call out the case of one showing
>up in an out-of-dialog message.
>>
>>
>>I would not expect there to be a Session-ID header in a 100 Trying since
>>
>>it's not generated by an endpoint.  Since 9.2 is a little busy, would you
>>
>>rather see this in 9.1?
>>_REALLY_?
>>I don't expect the working group to agree with you, but let's ask.
>>Those folks wanting to be able to grab messages to do diagnostics
>>are going to be _seriously_ interested in those hop-by-hop cancels,
>>100s, 200 OKs, and ACKs.
>>
>>PEJ: I didn't speak of CANCEL or 200, just 100 Trying.  What would 
>>make sense in a 100?
>Whatever appeared in the INVITE the 100 is squelching the retransmissions of
>(with local and remote reversed).
>That squelching of retransmissions is why the people that are 
>looking at using this for diagnostic
>purposes are going to really want to be able to find those 100s.
>
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: Robert Sparks <[email-masked]>
Date: Tue, 09 Jul 2013 17:10:05 -0500

On 7/3/13 7:02 PM, James Polk wrote:
> Robert
>
> Can you pick out a call flow from an existing RFC or ID that you would 
> like for me to add in a Session-ID to for each of the following messages:
>
> - 100 Trying
> - CANCEL and
I went looking for a minimal call flow that showed 100 Trying with forking.
I was really surprised to not find a good one in the RFC series already 
(unless I've just missed it).

You can get started with https://datatracker.ietf.org/doc/rfc3665 
section 3.8, but it will miss
the important differences you will get into when you have more than one 
branch in a fork (particularly
if each leg has established early media) that I think you should consider.

I'll ask on sipcore if anybody else can find an already published 
example that I've missed. If not, I'll make
one for you.
> - whatever other messages you would like to see in s9
You asked separately about OOD refer - you might look at 5589 section 
6.1 for that one.

RjS
>>> PEJ: I got the point.  What you said is correct, which is why I used 
>>> the language "sender of the message".  If that's not clear, how can 
>>> we make it clear?
>> Now, for the martian value conversation, using this figure again, but 
>> still trimming heavily:
>>>
>>> something that's not written clearly, since I know what I expect.   
>>> But, I'm missing why it's not clear.  In the above flow, Alice 
>>> received a message from B to her (A).
>> wouldn't also have lead to there being a non-empty to-tag? If it did, 
>> Alice would reject the message with a 481. If you _can_ think of a 
>> circumstance where Alice would get an initial message with a 
>> That squelching of retransmissions is why the people that are looking 
>> at using this for diagnostic

---

From: Robert Sparks <[email-masked]>
Date: Wed, 10 Jul 2013 15:43:36 -0500

Dale suggests:

rfc 5359 section 2.9

That's a good starting point - it has 180s from two legs.
I think it would help illuminate things to add 100s before those 180s, 
and replace the 180s with 183s (with answers).

The forking shown there is serial, but it should still help make sure 
we're thinking about what the right values are - please think through 
what would be different, if anything, if the forking were parallel (both 
legs active at the same time).

Thanks again Dale!

RjS

On 7/9/13 5:10 PM, Robert Sparks wrote:
> I was really surprised to not find a good one in the RFC series 
> already (unless I've just missed it).
>
> the important differences you will get into when you have more than 
> one branch in a fork (particularly