From rjsparks@nostrum.com Wed Apr 3 14:20:26 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31CB21F8FDD for ; Wed, 3 Apr 2013 14:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwyUWZ8Nw19j for ; Wed, 3 Apr 2013 14:20:25 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E88B721F8FDC for ; Wed, 3 Apr 2013 14:20:24 -0700 (PDT) Received: from unnumerable.tekelec.com ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r33LKOeM009805 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Wed, 3 Apr 2013 16:20:24 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <515C9D18.706@nostrum.com> Date: Wed, 03 Apr 2013 16:20:24 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: insipid@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [Insipid] Comments on draft-ietf-insipid-session-id-00 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 21:20:26 -0000 Some things I noted while reading through this document and formulating the definition I proposed. In section 4 paragraph 5, we need to account for the possibility that you can have multiple 200 OKs or that the INVITE may pend forever, and you never get any 200 OKs. That is, each of the session listed here may become full fledged "calls". The current text strongly implies that all but one of them are ephemeral things. The text (probably somewhere in section 5 or very early in section 6) should be more forceful in pointing out that the sense of the remote part of this identifier is treated exactly the opposite in responses than the related from and to tags. It's an ok decision for the group to make, but unless you make it _extremely_ obvious, it's very likely that an implementer would reuse their "what tag to I put in the To: of responses" logic. Section 6, paragraph 1: s/all messages transmitted/all SIP messages transmitted/ Section 6 needs to make it clear what an intermediary sending a hop-by-hop SIP message (such as a 100 trying, or a CANCEL) must or must not include for a Session-ID. I noted that after the end of the second paragraph - maybe that's a good place for the discussion? Section 6 paragraph 3 is out of place - it breaks the flow of the endpoint behavior section. I suspect it needs a section of its own, and it needs to say more. If a UA gets a remote parameter that does not match what it thought it was, should it start _using_ the parameter value it received in any subsequent messages it sends, or should it stick with what it thought it's end was supposed to be? I'm assuming the latter, given paragraph 5 (which I think should also be moved along with paragraph 3. Either way, the text needs to be explicit. Section 7. How is the first paragraph useful? It's either underspecified, or not needed. Currently, the document says the same thing if you delete it. Section 8 first paragraph: What happens if the MCU gets one of the alien UUIDs mentioned in section 6 paragraph 3? What would a system that was gathering all the messages related to the conference do (as hinted in the second paragraph)? Wouldn't it miss such a message since it wouldn't have the UUID the MCU had created in it? Or are you expecting you would find it through a chain of association with whatever happened at the endpoint that sent the martian? A MCU |<-- {MCU} -- | |--- {A,MCU}->| |<--{MCU, A}--| |-- {A,MARS}->| Section 9 needs to be recast explicitly as examples. It is very confusing to have things in examples labelled "Rules" or appear to be defining operation. Section 9.2 should show a 100 Trying Consider adding a variant of 9.2 that sends the REFER out-of-dialog - would such a thing have the same session-id or a different one? The example in Section 9.3 is broken. As drawn, Carol and Alice would be very surprised when the media they just started exchanging went away as bob causes Carol's UA to hang up. From rjsparks@nostrum.com Wed Apr 3 14:22:02 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7D221F8FF8 for ; Wed, 3 Apr 2013 14:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4bE+9PT3bVx for ; Wed, 3 Apr 2013 14:22:01 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 209C721F8FF5 for ; Wed, 3 Apr 2013 14:22:01 -0700 (PDT) Received: from unnumerable.tekelec.com ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r33LM0Xd009983 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Wed, 3 Apr 2013 16:22:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <515C9D78.6000809@nostrum.com> Date: Wed, 03 Apr 2013 16:22:00 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: insipid@ietf.org References: <515C9733.1080803@nostrum.com> In-Reply-To: <515C9733.1080803@nostrum.com> X-Forwarded-Message-Id: <515C9733.1080803@nostrum.com> Content-Type: multipart/alternative; boundary="------------060609060306050206050505" Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [Insipid] A definition of "session" for the purposes of Insipid X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 21:22:02 -0000 This is a multi-part message in MIME format. --------------060609060306050206050505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To make some progress on the discussion around defining what we are trying to identify, I propose adding the following to the requirements document as a section before "Terminology" and modifying the rest of the document text to be consistent with what's said here. ------ 3. What does the Session-ID Identify? The identifier this document places requirements on identifies a set of signaling messages associated with exactly two endpoints that, from each endpoint's perspective, are related to a single invocation of a communication application. How the endpoints determine which signaling messages share a given identifier (that is, what constitutes a single invocation of a communication application) is intentionally left loosely defined. The term "call" is often used as an example of such an invocation for voice and video communication, but different protocols and deployments define the scope of a "call" in different ways. For instance, some systems would associate all of the activity between all three parties involved in a transfer a single "call". Similarly, the term "session" is often used as an example of such an invocation, but this term is overloaded to describe both signaling and media level interaction. A single invocation of the communication application, as described above, may involve multiple RTP "sessions" as described by RFC3550, possibly even multiple concurrent sessions. In this document, unless otherwise qualified, the term "session" will refer only to the set of of signaling messages identified by the common Session-ID identifier. That is, a "session" is a set of signaling messages associated with exactly two endpoints that, from each endpoint's perspective, are related to a single invocation of a communication application. The requirements in this document put some constraint on what an endpoint will consider the same, or a different, invocation of a communication session. They also ensure that related sessions (as this document is using the term) can be correlated using only the session identifiers for each session. Again, what constitutes a "related" session is intentionally left loosely defined. The definition speaks of messages associated with exactly two endpoints instead of messages sent between two endpoints to allow for intermediaries that create messages on an endpoints behalf. It is possible that an endpoint may not see all of the messages in a session (as this document is using the term) associated with it. This definition, and the requirements in this document that put some constraint on what an endpoint should consider the same, or a different, invocation of a communication session facilitates specifying an identifier that allows the two endpoints to be using two entirely different protocols (hence potentially have different ideas of what a single invocation means) or be using two applications that have a different idea of what a single invocation means. --------------060609060306050206050505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
To make some progress on the discussion around defining what we are trying to identify, I propose adding the following to the requirements document as a section before "Terminology" and modifying the rest of the document text to be consistent with what's said here.

------

3. What does the Session-ID Identify?

The identifier this document places requirements on identifies a set of signaling messages associated with exactly two endpoints that, from each endpoint's perspective, are related to a single invocation of a communication application.

How the endpoints determine which signaling messages share a given identifier (that is, what constitutes a single invocation of a communication application) is intentionally left loosely defined.

The term "call" is often used as an example of such an invocation for voice and video communication, but different protocols and deployments define the scope of a "call" in different ways. For instance, some systems would associate all of the activity between all three parties involved in a transfer a single "call".

Similarly, the term "session" is often used as an example of such an invocation, but this term is overloaded to describe both signaling and media level interaction.  A single invocation of the communication application, as described above, may involve multiple RTP "sessions" as described by RFC3550, possibly even multiple concurrent sessions.

In this document, unless otherwise qualified, the term "session" will refer only to the set of of signaling messages identified by the common Session-ID identifier. That is, a "session" is a set of signaling messages associated with exactly two endpoints that, from each endpoint's perspective, are related to a single invocation of a communication application.

The requirements in this document put some constraint on what an endpoint will consider the same, or a different, invocation of a communication session. They also ensure that related sessions (as this document is using the term) can be correlated using only the session identifiers for each session. Again, what constitutes a "related" session is intentionally left loosely defined.

The definition speaks of messages associated with exactly two endpoints instead of messages sent between two endpoints to allow for intermediaries that create messages on an endpoints behalf. It is possible that an endpoint may not see all of the messages in a session (as this document is using the term) associated with it.

This definition, and the requirements in this document that put some constraint on what an endpoint should consider the same, or a different, invocation of a communication session facilitates specifying an identifier that allows the two endpoints to be using two entirely different protocols (hence potentially have different ideas of what a single invocation means) or be using two applications that have a different idea of what a single invocation means.

--------------060609060306050206050505-- From paulej@packetizer.com Tue Apr 9 13:31:43 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526A221F985F for ; Tue, 9 Apr 2013 13:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFadyboVRVco for ; Tue, 9 Apr 2013 13:31:42 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 10A9A21F985E for ; Tue, 9 Apr 2013 13:31:38 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r39KV9wW019008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Apr 2013 16:31:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1365539470; bh=2iRkzh9c6WZETHzU6ycx/FKRk4KcUn9tZw7eEtTTI+c=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=M7MEF13OGKjSM2sp2RL1LYV8AKEB9QxNjPFNrtVfcdfD1cYgYHtKVmmVKQa0rdwPb 59zPsuCiEBnilAfbcQkFpllCVy6VhiCAQcZYDu0N9BIkUKoI/P2MZpQlKIK08QkcxF 7cMDnbfpFxoHCFFGyMCn8mDYhnsvzz2a2VH3Fj0I= From: "Paul E. Jones" To: "'Charles Eckel \(eckelcu\)'" , "'Brett Tate'" , "'James Polk \(jmpolk\)'" , References: <576A8B541C219D4E9CEB1DF8C19C7B88196A55D1@MBX07.citservers.local> <201303291747.r2THlHFO006920@rcdn-core2-1.cisco.com> <576A8B541C219D4E9CEB1DF8C19C7B88196A5629@MBX07.citservers.local> <92B7E61ADAC1BB4F941F943788C08828047DF088@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047DF088@xmb-aln-x08.cisco.com> Date: Tue, 9 Apr 2013 16:31:15 -0400 Message-ID: <0b4401ce3561$2f423110$8dc69330$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKzQ5ZvVePuJ9Lf75cKYNFyX3X2+gEL1nb/AZxJCCYCKlWA1ZbdpP8A Content-Language: en-us Subject: Re: [Insipid] disaggregated media: call origination X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 20:31:43 -0000 Charles, > Perhaps this requirement needs be to expanded a bit to differentiate > between proxies and B2BUA. For a proxy, in think the existing wording of > Req 3 is fine. For a B2BUA, the requirement needs to be changed to state > that 'M', in this example, remains unchanged rather than the entire > identifier remains unchanged. I don't think it's a matter of B2BUA vs. Proxy. We want both to pass the UUIDs along transparently. However, the disaggregated media flow is a special case because the B2BUA is acting like a gateway. Basically, it's fully-terminating the SIP signaling and originating new calls to both Bob's computer (Bc) and phone (Bp). In the flow Brett originally presented and the flow that James drew up, it appeared to me that the B2BUA received a call from Alice, then initiated communication with Bc and Bp. Perhaps the "From" header going to both devices still said "Alice". Perhaps the Call-ID was the same, too. However, if Bob's phone and computer answered, what "tag" does the B2BUA send back to Alice? Something Bc returned or something Bp returned? Or something entirely different? The B2BUA has to make a choice. As far as we could see, this call flow looked like a conference call where the B2BUA was acting like a PBX/MCU/other. It was "terminating" the call from Alice and then inviting Bp and Bc into the conference. Media would go directly from Bp and Bc to Alice, perhaps, but it was clear that the B2BUA was playing tricks with the signaling. So, the call flow James prepared tried to address this special case. Paul From paulej@packetizer.com Tue Apr 9 15:39:39 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D1421F9399 for ; Tue, 9 Apr 2013 15:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA4myxeTsN75 for ; Tue, 9 Apr 2013 15:39:38 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2277021F9357 for ; Tue, 9 Apr 2013 15:39:38 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r39MdamS026035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Apr 2013 18:39:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1365547177; bh=sdY4B9L2b4mDEnXXOS2pKpSCWXbovBS1zAEEkySwWG4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=tDUyrIuevxSwR634ECDZIpX5wleSckAuGMZNMhkKx1+5OSGAZcCu+rbUV0q9+oryn 9ICj98comAjWmT5d92A4hjONTcJ+w5jqLX1UYDDk/2FCuOKdxJbFOUxcPiKC+iVpT4 PhCTQZ9hbi6DMMnz5/5FtwlO4engQSdUZqFuD/qk= From: "Paul E. Jones" To: "'Robert Sparks'" , References: <515C9D18.706@nostrum.com> In-Reply-To: <515C9D18.706@nostrum.com> Date: Tue, 9 Apr 2013 18:39:42 -0400 Message-ID: <0b5b01ce3573$20f1c5f0$62d551d0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+Gwhq2SbtlOTSELR/UdBeheRutZhukJaQ Content-Language: en-us Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-00 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 22:39:39 -0000 Robert, My apologies for the belated reply. I've been extremely busy this past week or so. > In section 4 paragraph 5, we need to account for the possibility that > you can have multiple 200 OKs or > that the INVITE may pend forever, and you never get any 200 OKs. That > is, each of the session listed > here may become full fledged "calls". The current text strongly implies > that all but one of them are > ephemeral things. Perhaps the issue is the language " Until one UA returns a 200 OK to the initial INVITE," If we delete that wording, would it help? The intent is that the communication session between Alice and Bob-1 can be identified independently from that communication session between Alice and Bob-2, and using different UUIDs at each device makes this possible. > The text (probably somewhere in section 5 or very early in section 6) > should be more forceful in pointing > out that the sense of the remote part of this identifier is treated > exactly the opposite in responses than > the related from and to tags. It's an ok decision for the group to make, > but unless you make it _extremely_ > obvious, it's very likely that an implementer would reuse their "what > tag to I put in the To: of responses" logic. How about this right at the end of the first paragraph in Section 6? "The UUID of the sender of the message MUST appear first in the Session-ID header and the UUID of the peer device, if known, must appear as the "remote" parameter following the sender's UUID." But now that you ask this... :-) Suppose Alice send an INVITE to Bob and receives Bob-1, Bob-2, and Bob-3 UUIDs. Now suppose Alice wants to send an UPDATE? What UUID does Alice put as the "remote" parameter? (Originally, we did not have the "remote" parameter, since we knew this value would be different for very Bob-x that replied.) > Section 6, paragraph 1: s/all messages transmitted/all SIP messages > transmitted/ OK > Section 6 needs to make it clear what an intermediary sending a > hop-by-hop SIP message (such as a 100 trying, > or a CANCEL) must or must not include for a Session-ID. I noted that > after the end of the second paragraph - maybe > that's a good place for the discussion? Section 7 is intended to discuss intermediary behavior and it says intermediaries must not alter the UUID values. Whether it adds them or not should be optional and that is also covered in Section 7. So, what is missing, exactly? > Section 6 paragraph 3 is out of place - it breaks the flow of the > endpoint behavior section. I suspect it needs > a section of its own, and it needs to say more. I think the paragraph is in the right place, because we're still talking about Bob here. I think what's confusing is the use of the words "non-intermediary UAS". We're talking about Bob, but there was a request to make the point that we're not talking about intermediaries when we speak of this section. If we replace "non-intermediary UAS" with "UA", would this sound better? > If a UA gets a remote > parameter that does not match what it thought > it was, should it start _using_ the parameter value it received in any > subsequent messages it sends, or should it stick > with what it thought it's end was supposed to be? I'm assuming the > latter, given paragraph 5 (which I think should > also be moved along with paragraph 3. Either way, the text needs to be > explicit. The "remote" parameter that Alice would receive in a message is her UUID. If it's wrong, she should ignore it. I think your question is if Bob receives one "local-UUID" value in an INVITE and 20 minutes later there is a new INVITE for the same call with a different "local-UUID" value, which value should Bob use in subsequent messages? The answer would be the most recently received "local-UUID" value. How about I change paragraph 5 of Section 6 to read (new text surrounded by __): "An endpoint MUST assume that the UUID value of the peer UA MAY change at any time due to service interactions. __If the UUID value of the peer UA changes, the UA MUST include this new UUID as the "remote" parameter in any subsequent messages.__ However, once a UA allocates a UUID value for a communication session, the UA MUST NOT change that UUID value..." I would further like to suggest we split this paragraph. It deals with two topics: the fact that an endpoint never changes its own UUID for a session and the fact that the remote UUID might change due to service interaction. > Section 7. How is the first paragraph useful? It's either > underspecified, or not needed. Currently, the document says > the same thing if you delete it. Probably not terrible useful. It's more informative than normative, I think. I'll remove it. > Section 8 first paragraph: What happens if the MCU gets one of the alien > UUIDs mentioned in section 6 paragraph 3? The MCU is only interested in the "local-UUID" field. It would not get an alien value there. If a device participating in a conference uses some non-standard means of transferring the call to a new endpoint, the MCU might see a new "local-UUID" value. That's expected as described in Section 6. (The MCU is just an endpoint.) > What would a system that was gathering all the messages related to the > conference do (as hinted in the second paragraph)? Whatever it wanted to do. The intent is not prescribe what a devices is to do with values like: {A, B} {A, C} {A, D} Rather, it is there to show that one might assume some kind of relationship. It might be a conference call, or it might be that A called B, B transferred the call to C, and C transferred the call to D. > Wouldn't it miss such a message since it wouldn't have the UUID the MCU > had created in it? Or are you expecting you would > find it through a chain of association with whatever happened at the > endpoint that sent the martian? > > A MCU > |<-- {MCU} -- | > |--- {A,MCU}->| > |<--{MCU, A}--| > |-- {A,MARS}->| I'm not sure how MARS got into that flow. Why would A send a UUID that had never been part of these flows? > Section 9 needs to be recast explicitly as examples. It is very > confusing to have things in examples labelled "Rules" or appear > to be defining operation. New second paragraph in 9 that says this? "This section is for illustrative purposes only and is non-normative." > Section 9.2 should show a 100 Trying 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? > Consider adding a variant of 9.2 that sends the REFER out-of-dialog - > would such a thing have the same session-id or a different one? Given that an OOD REFER is not part of a session, then that should introduce a new Session-ID UUID, right? > The example in Section 9.3 is broken. As drawn, Carol and Alice would be > very surprised when the media they just started exchanging went away as > bob causes Carol's UA to hang up. I assume the offending part is: {B,A} |<-----BYE-------| | | {A,B} |-----200 OK---->| | | That should not be going to Alice. Paul From paulej@packetizer.com Tue Apr 9 15:50:13 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3052721F978F for ; Tue, 9 Apr 2013 15:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f9-7pNxBbsq for ; Tue, 9 Apr 2013 15:50:10 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BFB4521F978D for ; Tue, 9 Apr 2013 15:50:07 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r39Mo6JJ026637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Apr 2013 18:50:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1365547807; bh=Y6wxnArqTSVU9oqz084cJUEPsH8e+ytxCNpCZxVcaDg=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=O7Nl5kM3SrlzVORAap7XuICvu6TJmiB4eO/fMnWNNdS4wczo8h1ihtjuUceT2dq1j XznyXq8a7c+Oxlkph0m9ZmNEGjENZi7I72Qu+cp6D659+ZYOW9rhk59Jh9RHWfDTh1 iSYgUO2oDZp+Jbn0ar82SIGcFbQqh2R0mzNdlRzY= From: "Paul E. Jones" To: "'Robert Sparks'" , References: <515C9733.1080803@nostrum.com> <515C9D78.6000809@nostrum.com> In-Reply-To: <515C9D78.6000809@nostrum.com> Date: Tue, 9 Apr 2013 18:50:12 -0400 Message-ID: <0b7201ce3574$98574e20$c905ea60$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B73_01CE3553.11464A60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG0rR+Fuxe36esdVKYzBuIcTHYMiAE7dFidmPezKbA= Content-Language: en-us Subject: Re: [Insipid] A definition of "session" for the purposes of Insipid X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 22:50:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B73_01CE3553.11464A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Robert, This sounds good. Now, given this, is there text in the "new" section 4 you think needs to change? Paul From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Wednesday, April 03, 2013 5:22 PM To: insipid@ietf.org Subject: [Insipid] A definition of "session" for the purposes of Insipid To make some progress on the discussion around defining what we are trying to identify, I propose adding the following to the requirements document as a section before "Terminology" and modifying the rest of the document text to be consistent with what's said here. ------ 3. What does the Session-ID Identify? The identifier this document places requirements on identifies a set of signaling messages associated with exactly two endpoints that, from each endpoint's perspective, are related to a single invocation of a communication application. How the endpoints determine which signaling messages share a given identifier (that is, what constitutes a single invocation of a communication application) is intentionally left loosely defined. The term "call" is often used as an example of such an invocation for voice and video communication, but different protocols and deployments define the scope of a "call" in different ways. For instance, some systems would associate all of the activity between all three parties involved in a transfer a single "call". Similarly, the term "session" is often used as an example of such an invocation, but this term is overloaded to describe both signaling and media level interaction. A single invocation of the communication application, as described above, may involve multiple RTP "sessions" as described by RFC3550, possibly even multiple concurrent sessions. In this document, unless otherwise qualified, the term "session" will refer only to the set of of signaling messages identified by the common Session-ID identifier. That is, a "session" is a set of signaling messages associated with exactly two endpoints that, from each endpoint's perspective, are related to a single invocation of a communication application. The requirements in this document put some constraint on what an endpoint will consider the same, or a different, invocation of a communication session. They also ensure that related sessions (as this document is using the term) can be correlated using only the session identifiers for each session. Again, what constitutes a "related" session is intentionally left loosely defined. The definition speaks of messages associated with exactly two endpoints instead of messages sent between two endpoints to allow for intermediaries that create messages on an endpoints behalf. It is possible that an endpoint may not see all of the messages in a session (as this document is using the term) associated with it. This definition, and the requirements in this document that put some constraint on what an endpoint should consider the same, or a different, invocation of a communication session facilitates specifying an identifier that allows the two endpoints to be using two entirely different protocols (hence potentially have different ideas of what a single invocation means) or be using two applications that have a different idea of what a single invocation means. ------=_NextPart_000_0B73_01CE3553.11464A60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Robert,

 

This sounds good.  Now, given this, is there text in the = “new” section 4 you think needs to = change?

 

Paul

 

From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On = Behalf Of Robert Sparks
Sent: Wednesday, April 03, 2013 = 5:22 PM
To: insipid@ietf.org
Subject: [Insipid] A = definition of "session" for the purposes of = Insipid

 

To make some = progress on the discussion around defining what we are trying to = identify, I propose adding the following to the requirements document as = a section before "Terminology" and modifying the rest of the = document text to be consistent with what's said here.

------ =

3. What does the Session-ID Identify?

The identifier = this document places requirements on identifies a set of signaling = messages associated with exactly two endpoints that, from each = endpoint's perspective, are related to a single invocation of a = communication application.

How the endpoints determine which = signaling messages share a given identifier (that is, what constitutes a = single invocation of a communication application) is intentionally left = loosely defined.

The term "call" is often used as an = example of such an invocation for voice and video communication, but = different protocols and deployments define the scope of a = "call" in different ways. For instance, some systems would = associate all of the activity between all three parties involved in a = transfer a single "call".

Similarly, the term = "session" is often used as an example of such an invocation, = but this term is overloaded to describe both signaling and media level = interaction.  A single invocation of the communication application, = as described above, may involve multiple RTP "sessions" as = described by RFC3550, possibly even multiple concurrent sessions. =

In this document, unless otherwise qualified, the term = "session" will refer only to the set of of signaling messages = identified by the common Session-ID identifier. That is, a = "session" is a set of signaling messages associated with = exactly two endpoints that, from each endpoint's perspective, are = related to a single invocation of a communication application. =

The requirements in this document put some constraint on what an = endpoint will consider the same, or a different, invocation of a = communication session. They also ensure that related sessions (as this = document is using the term) can be correlated using only the session = identifiers for each session. Again, what constitutes a = "related" session is intentionally left loosely defined. =

The definition speaks of messages associated with exactly two = endpoints instead of messages sent between two endpoints to allow for = intermediaries that create messages on an endpoints behalf. It is = possible that an endpoint may not see all of the messages in a session = (as this document is using the term) associated with it.

This = definition, and the requirements in this document that put some = constraint on what an endpoint should consider the same, or a different, = invocation of a communication session facilitates specifying an = identifier that allows the two endpoints to be using two entirely = different protocols (hence potentially have different ideas of what a = single invocation means) or be using two applications that have a = different idea of what a single invocation means. =

------=_NextPart_000_0B73_01CE3553.11464A60-- From rjsparks@nostrum.com Tue Apr 9 17:01:46 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F9221F97AF for ; Tue, 9 Apr 2013 17:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbxPWVX3HSki for ; Tue, 9 Apr 2013 17:01:44 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7762D21F9799 for ; Tue, 9 Apr 2013 17:01:43 -0700 (PDT) Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3A01fOo090363 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Tue, 9 Apr 2013 19:01:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5164ABE5.9010602@nostrum.com> Date: Tue, 09 Apr 2013 19:01:41 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Paul E. Jones" References: <515C9D18.706@nostrum.com> <0b5b01ce3573$20f1c5f0$62d551d0$@packetizer.com> In-Reply-To: <0b5b01ce3573$20f1c5f0$62d551d0$@packetizer.com> Content-Type: multipart/alternative; boundary="------------040903020100070005000102" Received-SPF: pass (shaman.nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism) Cc: insipid@ietf.org Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-00 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 00:01:46 -0000 This is a multi-part message in MIME format. --------------040903020100070005000102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/9/13 5:39 PM, Paul E. Jones wrote: > Robert, > > My apologies for the belated reply. I've been extremely busy this past week > or so. > >> In section 4 paragraph 5, we need to account for the possibility that >> you can have multiple 200 OKs or >> that the INVITE may pend forever, and you never get any 200 OKs. That >> is, each of the session listed >> here may become full fledged "calls". The current text strongly implies >> that all but one of them are >> ephemeral things. > Perhaps the issue is the language " Until one UA returns a 200 OK to the > initial INVITE," > > If we delete that wording, would it help? The intent is that the > communication session between Alice and Bob-1 can be identified > independently from that communication session between Alice and Bob-2, and > using different UUIDs at each device makes this possible. It would help, but look for more - right now, the text still has more of a flavor of a "call"-like thing rather than a dialog-like thing. You're wanting to be more dialog-like here. > >> The text (probably somewhere in section 5 or very early in section 6) >> should be more forceful in pointing >> out that the sense of the remote part of this identifier is treated >> exactly the opposite in responses than >> the related from and to tags. It's an ok decision for the group to make, >> but unless you make it _extremely_ >> obvious, it's very likely that an implementer would reuse their "what >> tag to I put in the To: of responses" logic. > How about this right at the end of the first paragraph in Section 6? > > "The UUID of the sender of the message MUST appear first in the Session-ID > header and the UUID of the peer device, if known, must appear as the > "remote" parameter following the sender's UUID." You missed the important part of my point. The issue is that you are treating the session-id differently in _responses_ than SIP treats to and from tags in responses. The from-tag in a response is going to be _exactly_ what it was in a request. The local part of the Session ID is going to be _different_ in a response than it was in the request. Let me try this with two example (partial) messages - Lets use a BYE and its associated 200 OK BYE sip:yadda@example.com SIP/2.0 To: sip:foo@example.com;tag=aTagThatFooMade From: sip:bar@example.com;tag=aTagThatBarMade Session-ID: <32 characters of stuff bar made up>;remote=<32 characters of stuff foo made up> SIP/2.0 200 OK To: sip:foo@example.com;tag=aTagThatFooMade From: sip:bar@example.com;tag=aTagThatBarMade Session-ID: <32 characters of stuff foo made up>;remote=<32 characters of stuff bar made up> This is a consequence of this sentence from section 5: The "local-uuid" in the Session-ID header represents the UUID value of the UA transmitting the message. Bar transmitted the request message (the BYE), and Foo transmitted the response message (the 200 OK). I'm assuming you wanted that to be different than from how tags are handled on purpose. That's fine, but we should be proactive in pointing that difference out. > > But now that you ask this... :-) > > Suppose Alice send an INVITE to Bob and receives Bob-1, Bob-2, and Bob-3 > UUIDs. > > Now suppose Alice wants to send an UPDATE? What UUID does Alice put as the > "remote" parameter? (Originally, we did not have the "remote" parameter, > since we knew this value would be different for very Bob-x that replied.) This is a no-brainer. She will use the UUID for the instance of Bob-X that she's sending the UPDATE to. Remember that an UPDATE sent in a dialog like this goes to one particular dialog, and the remote target established by that dialog. It will not fork. If Alice is wanting to affect all of the Bob-X, she will need to send an UPDATE to each of them, each using UUID provided by that particular Bob-X. > >> Section 6, paragraph 1: s/all messages transmitted/all SIP messages >> transmitted/ > OK > >> Section 6 needs to make it clear what an intermediary sending a >> hop-by-hop SIP message (such as a 100 trying, >> or a CANCEL) must or must not include for a Session-ID. I noted that >> after the end of the second paragraph - maybe >> that's a good place for the discussion? > Section 7 is intended to discuss intermediary behavior and it says > intermediaries must not alter the UUID values. Whether it adds them or not > should be optional and that is also covered in Section 7. So, what is > missing, exactly? Proxies _source_ 100 Tryings and CANCELs. They don't forward them. Point to me where you think explaining what to put in either a 100 Trying or a Cancel is in the current text. I assert that you have not covered either message (or any other hop-by-hop message, such as an ACK to a non-200 final response to an INVITE). I suspect you are wanting to copy the logic that 3261 uses for populating the To and From headers (specifically the tags) for those messages (except for reversing the sense of what's remote in responses as above). But the document currently does not say that. A couple of quick examples here. You need to draw more in the document. (using S: as a shorthand for Session ID, and the {A}, {A,B}, {B,A} notation from the draft.) View this in a fixed width font A Proxy B1 B2 | Inv | | | | S: {A} | | | |----------->| | | | | Inv | | | | S: {A} | | | |-------------->| | | | Inv | | | | S: {A} | | | |---------------------------->| | | 603 Decline | | | | S: {B1,A} | | | |<--------------| | | | ACK | | | | S: {A,B1} | | | |-------------->| | | | CANCEL | | | 603 Decline| S: {A} | | | S: {B1,A} |---------------------------->| |<-----------| 200 OK (to the CANCEL) | | ACK | S: {B2,A} | | | S: {A,B1} |<----------------------------| |----------->| 487 Request Cancelled | | | S: {B2,A} | | |<----------------------------| | | ACK | | | S: {A,B2} | | |---------------------------->| I am _guessing_ at what you intended to be in that CANCEL and its 200 OK, and in the hop-by-hop ACKs. Did I guess correctly? What if B2 were another proxy - would it make up a B2 to put in the 200 OK to that cancel? The text needs to be clear about these things. >> Section 6 paragraph 3 is out of place - it breaks the flow of the >> endpoint behavior section. I suspect it needs >> a section of its own, and it needs to say more. > I think the paragraph is in the right place, because we're still talking > about Bob here. I think what's confusing is the use of the words > "non-intermediary UAS". We're talking about Bob, but there was a request to > make the point that we're not talking about intermediaries when we speak of > this section. If we replace "non-intermediary UAS" with "UA", would this > sound better? Uh, no. I'm talking about the paragraph that says 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. You appear to be talking about paragraph 2, not paragraph 3. > >> If a UA gets a remote >> parameter that does not match what it thought >> it was, should it start _using_ the parameter value it received in any >> subsequent messages it sends, or should it stick >> with what it thought it's end was supposed to be? I'm assuming the >> latter, given paragraph 5 (which I think should >> also be moved along with paragraph 3. Either way, the text needs to be >> explicit. > The "remote" parameter that Alice would receive in a message is her UUID. > If it's wrong, she should ignore it. Where does the document say that that Alice would ignore it? Again, I'm talking about that third paragraph of section 6 that I quote above. This is the "Martian" that I talk about below as well. Something sent a message to Alice containing a remote parameter that _should_ have been what Alice provided, but it wasn't. All you say is that Alice shouldn't treat that as an error. You don't say (yet) that she should ignore it. If that's what should happen you should go further and say endpoints should never even look at what they receive an the remote parameter. > > I think your question is if Bob receives one "local-UUID" value in an INVITE > and 20 minutes later there is a new INVITE for the same call with a > different "local-UUID" value, which value should Bob use in subsequent > messages? The answer would be the most recently received "local-UUID" > value. That was absolutely not my question. I hope you have it now from what's above, but I'll be graphic: What section 6 paragraph 3 says is that this can happen to Alice: (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) |<--------| 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. > > How about I change paragraph 5 of Section 6 to read (new text surrounded by > __): > "An endpoint MUST assume that the UUID value of the peer UA MAY change at > any time due to service interactions. __If the UUID value of the peer UA > changes, the UA MUST include this new UUID as the "remote" parameter in any > subsequent messages.__ However, once a UA allocates a UUID value for a > communication session, the UA MUST NOT change that UUID value..." > > I would further like to suggest we split this paragraph. It deals with two > topics: the fact that an endpoint never changes its own UUID for a session > and the fact that the remote UUID might change due to service interaction. That will help. > >> Section 7. How is the first paragraph useful? It's either >> underspecified, or not needed. Currently, the document says >> the same thing if you delete it. > Probably not terrible useful. It's more informative than normative, I > think. I'll remove it. > >> Section 8 first paragraph: What happens if the MCU gets one of the alien >> UUIDs mentioned in section 6 paragraph 3? > The MCU is only interested in the "local-UUID" field. It would not get an > alien value there. I'm sorry - there may be service interactions in processing a request it sends, and the response it gets has a Q in it, just like above. The fix you are working towards will handle this case. > If a device participating in a conference uses some > non-standard means of transferring the call to a new endpoint, the MCU might > see a new "local-UUID" value. That's expected as described in Section 6. > (The MCU is just an endpoint.) > >> What would a system that was gathering all the messages related to the >> conference do (as hinted in the second paragraph)? > Whatever it wanted to do. The intent is not prescribe what a devices is to > do with values like: > {A, B} > {A, C} > {A, D} > > Rather, it is there to show that one might assume some kind of relationship. > It might be a conference call, or it might be that A called B, B transferred > the call to C, and C transferred the call to D. > >> Wouldn't it miss such a message since it wouldn't have the UUID the MCU >> had created in it? Or are you expecting you would >> find it through a chain of association with whatever happened at the >> endpoint that sent the martian? >> >> A MCU >> |<-- {MCU} -- | >> |--- {A,MCU}->| >> |<--{MCU, A}--| >> |-- {A,MARS}->| > I'm not sure how MARS got into that flow. I hope you understand how that would happen now. Section 6 paragraph 3. > Why would A send a UUID that had > never been part of these flows? Maybe it would have helped if I drew A as an intermediary initially. > >> Section 9 needs to be recast explicitly as examples. It is very >> confusing to have things in examples labelled "Rules" or appear >> to be defining operation. > New second paragraph in 9 that says this? > "This section is for illustrative purposes only and is non-normative." That's not enough. Please don't be lazy. Change the text. > >> Section 9.2 should show a 100 Trying > 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. > >> Consider adding a variant of 9.2 that sends the REFER out-of-dialog - >> would such a thing have the same session-id or a different one? > Given that an OOD REFER is not part of a session, > then that should introduce > a new Session-ID UUID, right? Are you sure? Your ability to correlate the INVITES in a transfer goes out the window if you make that OOD part of a different session. You might want to see if the definition I sent will allow you to treat the OOD refer as part of the same session, or be explicit that you are not providing the ability to correlate the messages in this case. > >> The example in Section 9.3 is broken. As drawn, Carol and Alice would be >> very surprised when the media they just started exchanging went away as >> bob causes Carol's UA to hang up. > I assume the offending part is: > > {B,A} |<-----BYE-------| | | > {A,B} |-----200 OK---->| | | > > That should not be going to Alice. Correct. > > Paul > > > > --------------040903020100070005000102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 4/9/13 5:39 PM, Paul E. Jones wrote:
Robert,

My apologies for the belated reply.  I've been extremely busy this past week
or so.


In section 4 paragraph 5, we need to account for the possibility that
you can have multiple 200 OKs or
that the INVITE may pend forever, and you never get any 200 OKs. That
is, each of  the session listed
here may become full fledged "calls". The current text strongly implies
that all but one of them are
ephemeral things.

Perhaps the issue is the language " Until one UA returns a 200 OK to the
initial INVITE,"

If we delete that wording, would it help?  The intent is that the
communication session between Alice and Bob-1 can be identified
independently from that communication session between Alice and Bob-2, and
using different UUIDs at each device makes this possible.
It would help, but look for more - right now, the text still has more of a flavor
of a "call"-like thing rather than a dialog-like thing. You're wanting to be more
dialog-like here.
 

The text (probably somewhere in section 5 or very early in section 6)
should be more forceful in pointing
out that the sense of the remote part of this identifier is treated
exactly the opposite in responses than
the related from and to tags. It's an ok decision for the group to make,
but unless you make it _extremely_
obvious, it's very likely that an implementer would reuse their "what
tag to I put in the To: of responses" logic.

How about this right at the end of the first paragraph in Section 6?

"The UUID of the sender of the message MUST appear first in the Session-ID
header and the UUID of the peer device, if known, must appear as the
"remote" parameter following the sender's UUID."
You missed the important part of my point. The issue is that you are treating
the session-id differently in _responses_ than SIP treats to and from tags in
responses.

The from-tag in a response is going to be _exactly_ what it was in a request.

The local part of the Session ID is going to be _different_ in a response than it was in the request.

Let me try this with two example (partial) messages - Lets use a BYE and its associated 200 OK

BYE sip:yadda@example.com SIP/2.0
To: sip:foo@example.com;tag=aTagThatFooMade
From: sip:bar@example.com;tag=aTagThatBarMade
Session-ID: <32 characters of stuff bar made up>;remote=<32 characters of stuff foo made up>

SIP/2.0 200 OK
To: sip:foo@example.com;tag=aTagThatFooMade
From: sip:bar@example.com;tag=aTagThatBarMade
Session-ID: <32 characters of stuff foo made up>;remote=<32 characters of stuff bar made up>

This is a consequence of this sentence from section 5:
   The "local-uuid" in the Session-ID header represents the UUID value
   of the UA transmitting the message.

Bar transmitted the request message (the BYE), and Foo transmitted the response message (the 200 OK).

I'm assuming you wanted that to be different than from how tags are handled on purpose.
That's fine, but we should be proactive in pointing that difference out.



But now that you ask this... :-)

Suppose Alice send an INVITE to Bob and receives Bob-1, Bob-2, and Bob-3
UUIDs.

Now suppose Alice wants to send an UPDATE?  What UUID does Alice put as the
"remote" parameter?  (Originally, we did not have the "remote" parameter,
since we knew this value would be different for very Bob-x that replied.)
This is a no-brainer. She will use the UUID for the instance of Bob-X that
she's sending the UPDATE to. Remember that an UPDATE sent in a dialog
like this goes to one particular dialog, and the remote target established
by that dialog. It will not fork. If Alice is wanting to affect all of the Bob-X,
she will need to send an UPDATE to each of them, each using UUID provided
by that particular Bob-X.
 

Section 6, paragraph 1: s/all messages transmitted/all SIP messages
transmitted/

OK
 

Section 6 needs to make it clear what an intermediary sending a
hop-by-hop SIP message (such as a 100 trying,
or a CANCEL) must or must not include for a Session-ID. I noted that
after the end of the second paragraph - maybe
that's a good place for the discussion?

Section 7 is intended to discuss intermediary behavior and it says
intermediaries must not alter the UUID values.  Whether it adds them or not
should be optional and that is also covered in Section 7.  So, what is
missing, exactly?
Proxies _source_ 100 Tryings and CANCELs. They don't forward them.
Point to me where you think explaining what to put in either a 100 Trying
or a Cancel is in the current text. I assert that you have not covered either
message (or any other hop-by-hop message, such as an ACK to a non-200
final response to an INVITE).

I suspect you are wanting to copy the logic that 3261 uses for populating
the To and From headers (specifically the tags) for those messages (except
for reversing the sense of what's remote in responses as above). But the
document currently does not say that.

A couple of quick examples here. You need to draw more in the document.

(using S: as a shorthand for Session ID, and the {A}, {A,B}, {B,A} notation from the draft.)

View this in a fixed width font
 A          Proxy             B1           B2
 | Inv        |               |             |
 | S: {A}     |               |             |
 |----------->|               |             |
 |            | Inv           |             |
 |            | S: {A}        |             |
 |            |-------------->|             |
 |            | Inv           |             |
 |            | S: {A}        |             |
 |            |---------------------------->|
 |            | 603 Decline   |             |
 |            | S: {B1,A}     |             |
 |            |<--------------|             |
 |            | ACK           |             |
 |            | S: {A,B1}     |             |
 |            |-------------->|             |
 |            | CANCEL        |             |
 | 603 Decline| S: {A}        |             |
 | S: {B1,A}  |---------------------------->|            
 |<-----------| 200 OK (to the CANCEL)      |
 | ACK        | S: {B2,A}     |             |
 | S: {A,B1}  |<----------------------------|
 |----------->| 487 Request Cancelled       |
 |            | S: {B2,A}                   |
 |            |<----------------------------|
 |            | ACK                         |
 |            | S: {A,B2}                   |
 |            |---------------------------->|

I am _guessing_ at what you intended to be in that CANCEL and its 200 OK,
and in the hop-by-hop ACKs. Did I guess correctly? What if B2 were another
proxy - would it make up a B2 to put in the 200 OK to that cancel?

The text needs to be clear about these things.                                            

Section 6 paragraph 3 is out of place - it breaks the flow of the
endpoint behavior section. I suspect it needs
a section of its own, and it needs to say more.

I think the paragraph is in the right place, because we're still talking
about Bob here.  I think what's confusing is the use of the words
"non-intermediary UAS".  We're talking about Bob, but there was a request to
make the point that we're not talking about intermediaries when we speak of
this section.  If we replace "non-intermediary UAS" with "UA", would this
sound better?
Uh, no. I'm talking about the paragraph that says

   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.

You appear to be talking about paragraph 2, not paragraph 3.


If a UA gets a remote
parameter that does not match what it thought
it was, should it start _using_ the parameter value it received in any
subsequent messages it sends, or should it stick
with what it thought it's end was supposed to be? I'm assuming the
latter, given paragraph 5 (which I think should
also be moved along with paragraph 3. Either way, the text needs to be
explicit.

The "remote" parameter that Alice would receive in a message is her UUID.
If it's wrong, she should ignore it.
Where does the document say that that Alice would ignore it?
Again, I'm talking about that third paragraph of section 6 that I quote above.
This is the "Martian" that I talk about below as well. Something sent
a message to Alice containing a remote parameter that _should_ have been
what Alice provided, but it wasn't. All you say is that Alice shouldn't treat that
as an error. You don't say (yet) that she should ignore it. If that's what should
happen you should go further and say endpoints should never even look at what
they receive an the remote parameter.

I think your question is if Bob receives one "local-UUID" value in an INVITE
and 20 minutes later there is a new INVITE for the same call with a
different "local-UUID" value, which value should Bob use in subsequent
messages?  The answer would be the most recently received "local-UUID"
value.
That was absolutely not my question.
I hope you have it now from what's above, but I'll be graphic:
What section 6 paragraph 3 says is that this can happen to Alice:
(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)
  |<--------|

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.


How about I change paragraph 5 of Section 6 to read (new text surrounded by
__):
"An endpoint MUST assume that the UUID value of the peer UA MAY change at
any time due to service interactions.  __If the UUID value of the peer UA
changes, the UA MUST include this new UUID as the "remote" parameter in any
subsequent messages.__  However, once a UA allocates a UUID value for a
communication session, the UA MUST NOT change that UUID value..."

I would further like to suggest we split this paragraph.  It deals with two
topics: the fact that an endpoint never changes its own UUID for a session
and the fact that the remote UUID might change due to service interaction.
That will help.


Section 7. How is the first paragraph useful? It's either
underspecified, or not needed. Currently, the document says
the same thing if you delete it.

Probably not terrible useful.  It's more informative than normative, I
think.  I'll remove it.


Section 8 first paragraph: What happens if the MCU gets one of the alien
UUIDs mentioned in section 6 paragraph 3?

The MCU is only interested in the "local-UUID" field.  It would not get an
alien value there.
I'm sorry - there may be service interactions in processing a request it sends,
and the response it gets has a Q in it, just like above.  The fix you are working
towards will handle this case.
 If a device participating in a conference uses some
non-standard means of transferring the call to a new endpoint, the MCU might
see a new "local-UUID" value.  That's expected as described in Section 6.
(The MCU is just an endpoint.)


What would a system that was gathering all the messages related to the
conference do (as hinted in the second paragraph)?

Whatever it wanted to do. The intent is not prescribe what a devices is to
do with values like:
 {A, B}
 {A, C}
 {A, D}

Rather, it is there to show that one might assume some kind of relationship.
It might be a conference call, or it might be that A called B, B transferred
the call to C, and C transferred the call to D.


Wouldn't it miss such a message since it wouldn't have the UUID the MCU
had created in it? Or are you expecting you would
find it through a chain of association with whatever happened at the
endpoint that sent the martian?

A                    MCU
|<--  {MCU} -- |
|--- {A,MCU}->|
|<--{MCU, A}--|
|-- {A,MARS}->|

I'm not sure how MARS got into that flow.
I hope you understand how that would happen now. Section 6 paragraph 3.
  Why would A send a UUID that had
never been part of these flows?
Maybe it would have helped if I drew A as an intermediary initially.
 

Section 9 needs to be recast explicitly as examples. It is very
confusing to have things in examples labelled "Rules" or appear
to be defining operation.

New second paragraph in 9 that says this?
"This section is for illustrative purposes only and is non-normative."
That's not enough. Please don't be lazy. Change the text.


Section 9.2 should show a 100 Trying

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.
 

Consider adding a variant of 9.2 that sends the REFER out-of-dialog -
would such a thing have the same session-id or a different one?

Given that an OOD REFER is not part of a session,
 then that should introduce
a new Session-ID UUID, right?
Are you sure? Your ability to correlate the INVITES in a transfer goes out the window
if you make that OOD part of a different session. You might want to see if the
definition I sent will allow you to treat the OOD refer as part of the same session,
or be explicit that you are not providing the ability to correlate the messages in this case.
 

The example in Section 9.3 is broken. As drawn, Carol and Alice would be
very surprised when the media they just started exchanging went away as
bob causes Carol's UA to hang up.

I assume the offending part is:

     {B,A}      |<-----BYE-------|                |               |
     {A,B}      |-----200 OK---->|                |               |

That should not be going to Alice.
Correct.

Paul

--------------040903020100070005000102-- From rjsparks@nostrum.com Tue Apr 9 17:04:02 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A959321F95DF for ; Tue, 9 Apr 2013 17:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUC0+vtXSUzO for ; Tue, 9 Apr 2013 17:04:00 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C096821F936C for ; Tue, 9 Apr 2013 17:03:59 -0700 (PDT) Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3A03wfr090619 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Tue, 9 Apr 2013 19:03:58 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5164AC6E.1060802@nostrum.com> Date: Tue, 09 Apr 2013 19:03:58 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Paul E. Jones" References: <515C9733.1080803@nostrum.com> <515C9D78.6000809@nostrum.com> <0b7201ce3574$98574e20$c905ea60$@packetizer.com> In-Reply-To: <0b7201ce3574$98574e20$c905ea60$@packetizer.com> Content-Type: multipart/alternative; boundary="------------070504010105000103050108" Received-SPF: pass (shaman.nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism) Cc: insipid@ietf.org Subject: Re: [Insipid] A definition of "session" for the purposes of Insipid X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 00:04:02 -0000 This is a multi-part message in MIME format. --------------070504010105000103050108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/9/13 5:50 PM, Paul E. Jones wrote: > > Robert, > > This sounds good. Now, given this, is there text in the "new" section > 4 you think needs to change? > Definitely - the section can be simplified, and there are places that need to be adjusted to use this definition instead of try to define it itself by example. I hope you can see those spots. > > Paul > > *From:*insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] *On > Behalf Of *Robert Sparks > *Sent:* Wednesday, April 03, 2013 5:22 PM > *To:* insipid@ietf.org > *Subject:* [Insipid] A definition of "session" for the purposes of Insipid > > To make some progress on the discussion around defining what we are > trying to identify, I propose adding the following to the requirements > document as a section before "Terminology" and modifying the rest of > the document text to be consistent with what's said here. > > ------ > > 3. What does the Session-ID Identify? > > The identifier this document places requirements on identifies a set > of signaling messages associated with exactly two endpoints that, from > each endpoint's perspective, are related to a single invocation of a > communication application. > > How the endpoints determine which signaling messages share a given > identifier (that is, what constitutes a single invocation of a > communication application) is intentionally left loosely defined. > > The term "call" is often used as an example of such an invocation for > voice and video communication, but different protocols and deployments > define the scope of a "call" in different ways. For instance, some > systems would associate all of the activity between all three parties > involved in a transfer a single "call". > > Similarly, the term "session" is often used as an example of such an > invocation, but this term is overloaded to describe both signaling and > media level interaction. A single invocation of the communication > application, as described above, may involve multiple RTP "sessions" > as described by RFC3550, possibly even multiple concurrent sessions. > > In this document, unless otherwise qualified, the term "session" will > refer only to the set of of signaling messages identified by the > common Session-ID identifier. That is, a "session" is a set of > signaling messages associated with exactly two endpoints that, from > each endpoint's perspective, are related to a single invocation of a > communication application. > > The requirements in this document put some constraint on what an > endpoint will consider the same, or a different, invocation of a > communication session. They also ensure that related sessions (as this > document is using the term) can be correlated using only the session > identifiers for each session. Again, what constitutes a "related" > session is intentionally left loosely defined. > > The definition speaks of messages associated with exactly two > endpoints instead of messages sent between two endpoints to allow for > intermediaries that create messages on an endpoints behalf. It is > possible that an endpoint may not see all of the messages in a session > (as this document is using the term) associated with it. > > This definition, and the requirements in this document that put some > constraint on what an endpoint should consider the same, or a > different, invocation of a communication session facilitates > specifying an identifier that allows the two endpoints to be using two > entirely different protocols (hence potentially have different ideas > of what a single invocation means) or be using two applications that > have a different idea of what a single invocation means. > --------------070504010105000103050108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 4/9/13 5:50 PM, Paul E. Jones wrote:

Robert,

 

This sounds good.  Now, given this, is there text in the “new” section 4 you think needs to change?

Definitely - the section can be simplified, and there are places that need to be adjusted to use this definition instead of try to define it itself by example. I hope you can see those spots.

 

Paul

 

From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: Wednesday, April 03, 2013 5:22 PM
To: insipid@ietf.org
Subject: [Insipid] A definition of "session" for the purposes of Insipid

 

To make some progress on the discussion around defining what we are trying to identify, I propose adding the following to the requirements document as a section before "Terminology" and modifying the rest of the document text to be consistent with what's said here.

------

3. What does the Session-ID Identify?

The identifier this document places requirements on identifies a set of signaling messages associated with exactly two endpoints that, from each endpoint's perspective, are related to a single invocation of a communication application.

How the endpoints determine which signaling messages share a given identifier (that is, what constitutes a single invocation of a communication application) is intentionally left loosely defined.

The term "call" is often used as an example of such an invocation for voice and video communication, but different protocols and deployments define the scope of a "call" in different ways. For instance, some systems would associate all of the activity between all three parties involved in a transfer a single "call".

Similarly, the term "session" is often used as an example of such an invocation, but this term is overloaded to describe both signaling and media level interaction.  A single invocation of the communication application, as described above, may involve multiple RTP "sessions" as described by RFC3550, possibly even multiple concurrent sessions.

In this document, unless otherwise qualified, the term "session" will refer only to the set of of signaling messages identified by the common Session-ID identifier. That is, a "session" is a set of signaling messages associated with exactly two endpoints that, from each endpoint's perspective, are related to a single invocation of a communication application.

The requirements in this document put some constraint on what an endpoint will consider the same, or a different, invocation of a communication session. They also ensure that related sessions (as this document is using the term) can be correlated using only the session identifiers for each session. Again, what constitutes a "related" session is intentionally left loosely defined.

The definition speaks of messages associated with exactly two endpoints instead of messages sent between two endpoints to allow for intermediaries that create messages on an endpoints behalf. It is possible that an endpoint may not see all of the messages in a session (as this document is using the term) associated with it.

This definition, and the requirements in this document that put some constraint on what an endpoint should consider the same, or a different, invocation of a communication session facilitates specifying an identifier that allows the two endpoints to be using two entirely different protocols (hence potentially have different ideas of what a single invocation means) or be using two applications that have a different idea of what a single invocation means.


--------------070504010105000103050108-- From paulej@packetizer.com Tue Apr 9 23:43:47 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF74F21F9051 for ; Tue, 9 Apr 2013 23:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jN998sWr8BNl for ; Tue, 9 Apr 2013 23:43:41 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CBA0821F9007 for ; Tue, 9 Apr 2013 23:43:40 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r3A6hdk2020561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Apr 2013 02:43:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1365576220; bh=w7CdzdOFx73SSyZhSVZQPmi+2hdaokcSNOtzKj9oiJo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=kdqgfUJi3rklTxHHvCIK4yHq9FunwZcXkDwhvuN0KtV+H37rxvL6okDsUfN69a7mb kRjlIKS1rxQzNBjkVc9eq4hjQghYn2+V4lJ2FCbOz5Pg548D/3zPLH84x+69+vYSLt 4SmLpEfWN0ENgkqZgV2nagdg7m9ysTeGW2hLU/7k= From: "Paul E. Jones" To: "'Robert Sparks'" References: <515C9D18.706@nostrum.com> <0b5b01ce3573$20f1c5f0$62d551d0$@packetizer.com> <5164ABE5.9010602@nostrum.com> In-Reply-To: <5164ABE5.9010602@nostrum.com> Date: Wed, 10 Apr 2013 02:43:45 -0400 Message-ID: <0be001ce35b6$c026eea0$4074cbe0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BE1_01CE3595.39185BE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+Gwhq2SbtlOTSELR/UdBeheRutQLdSoPaAmz9fRqYRM5icA== Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-00 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 06:43:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0BE1_01CE3595.39185BE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Robert, Please see comments below (PEJ): The text (probably somewhere in section 5 or very early in section 6) should be more forceful in pointing out that the sense of the remote part of this identifier is treated exactly the opposite in responses than the related from and to tags. It's an ok decision for the group to make, but unless you make it _extremely_ obvious, it's very likely that an implementer would reuse their "what tag to I put in the To: of responses" logic. How about this right at the end of the first paragraph in Section 6? "The UUID of the sender of the message MUST appear first in the Session-ID header and the UUID of the peer device, if known, must appear as the "remote" parameter following the sender's UUID." You missed the important part of my point. The issue is that you are treating the session-id differently in _responses_ than SIP treats to and from tags in responses. 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? Section 6 needs to make it clear what an intermediary sending a hop-by-hop SIP message (such as a 100 trying, or a CANCEL) must or must not include for a Session-ID. I noted that after the end of the second paragraph - maybe that's a good place for the discussion? Section 7 is intended to discuss intermediary behavior and it says intermediaries must not alter the UUID values. Whether it adds them or not should be optional and that is also covered in Section 7. So, what is missing, exactly? Proxies _source_ 100 Tryings and CANCELs. They don't forward them. Point to me where you think explaining what to put in either a 100 Trying or a Cancel is in the current text. I assert that you have not covered either message (or any other hop-by-hop message, such as an ACK to a non-200 final response to an INVITE). PEJ: Ah, yes. now that point I missed. You're correct that this is not presently addressed. What confused me was that you were in Section 6, but this should be a topic of Section 7. I suspect you are wanting to copy the logic that 3261 uses for populating the To and From headers (specifically the tags) for those messages (except for reversing the sense of what's remote in responses as above). But the document currently does not say that. PEJ: For 100 Trying, the proxy would not be in a position to offer either UUID, unless it just fabricated a bogus value. We could do that, but is there value in doing so? A CANCEL could have valid values if the intermediary maintains state information (as shown in in your example below). I think we need suggestions on what to do here. I would hope this guidance could go into Section 7. A couple of quick examples here. You need to draw more in the document. (using S: as a shorthand for Session ID, and the {A}, {A,B}, {B,A} notation from the draft.) View this in a fixed width font A Proxy B1 B2 | Inv | | | | S: {A} | | | |----------->| | | | | Inv | | | | S: {A} | | | |-------------->| | | | Inv | | | | S: {A} | | | |---------------------------->| | | 603 Decline | | | | S: {B1,A} | | | |<--------------| | | | ACK | | | | S: {A,B1} | | | |-------------->| | | | CANCEL | | | 603 Decline| S: {A} | | | S: {B1,A} |---------------------------->| |<-----------| 200 OK (to the CANCEL) | | ACK | S: {B2,A} | | | S: {A,B1} |<----------------------------| |----------->| 487 Request Cancelled | | | S: {B2,A} | | |<----------------------------| | | ACK | | | S: {A,B2} | | |---------------------------->| I am _guessing_ at what you intended to be in that CANCEL and its 200 OK, and in the hop-by-hop ACKs. Did I guess correctly? What if B2 were another proxy - would it make up a B2 to put in the 200 OK to that cancel? PEJ: I'm inclined to say that a proxy initiating or replying to such messages should not include a Session-ID if it does not know what the endpoint UUIDs are. But, as I said, I'm open to input on this one. I don't know what the most appropriate thing is to do. The text needs to be clear about these things. PEJ: Agreed. I don't think it was considered before. Section 6 paragraph 3 is out of place - it breaks the flow of the endpoint behavior section. I suspect it needs a section of its own, and it needs to say more. I think the paragraph is in the right place, because we're still talking about Bob here. I think what's confusing is the use of the words "non-intermediary UAS". We're talking about Bob, but there was a request to make the point that we're not talking about intermediaries when we speak of this section. If we replace "non-intermediary UAS" with "UA", would this sound better? Uh, no. I'm talking about the paragraph that says 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. You appear to be talking about paragraph 2, not paragraph 3. PEJ: OK. That particular paragraph is then followed by a paragraph that is related. So, if we move that, we need to move the next. Actually, this whole section has undergone a bit of revision. I'll post the text to the list separately and let's work on the organization and wording. ;-) If a UA gets a remote parameter that does not match what it thought it was, should it start _using_ the parameter value it received in any subsequent messages it sends, or should it stick with what it thought it's end was supposed to be? I'm assuming the latter, given paragraph 5 (which I think should also be moved along with paragraph 3. Either way, the text needs to be explicit. The "remote" parameter that Alice would receive in a message is her UUID. If it's wrong, she should ignore it. Where does the document say that that Alice would ignore it? Again, I'm talking about that third paragraph of section 6 that I quote above. This is the "Martian" that I talk about below as well. Something sent a message to Alice containing a remote parameter that _should_ have been what Alice provided, but it wasn't. All you say is that Alice shouldn't treat that as an error. You don't say (yet) that she should ignore it. If that's what should happen you should go further and say endpoints should never even look at what they receive an the remote parameter. PEJ: I agree with your last statement: Alice should never even consider the "remote" parameter, as it's useless to her. However, we had a discussion on this point and folks said that Alice might want to log it. So, I unless folks want to retract the view, I can't write that she should ignore it. That's text that is in my version, but not yet published. That will be in the text I send to the list shortly. Let's consider that and further refine it. I think your question is if Bob receives one "local-UUID" value in an INVITE and 20 minutes later there is a new INVITE for the same call with a different "local-UUID" value, which value should Bob use in subsequent messages? The answer would be the most recently received "local-UUID" value. That was absolutely not my question. I hope you have it now from what's above, but I'll be graphic: What section 6 paragraph 3 says is that this can happen to Alice: (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) |<--------| 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, }. 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). Then she received a message from B to her, but this time mislabeled. I don't see how that can happen. 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. Section 8 first paragraph: What happens if the MCU gets one of the alien UUIDs mentioned in section 6 paragraph 3? The MCU is only interested in the "local-UUID" field. It would not get an alien value there. I'm sorry - there may be service interactions in processing a request it sends, and the response it gets has a Q in it, just like above. The fix you are working towards will handle this case. Wouldn't it miss such a message since it wouldn't have the UUID the MCU had created in it? Or are you expecting you would find it through a chain of association with whatever happened at the endpoint that sent the martian? A MCU |<-- {MCU} -- | |--- {A,MCU}->| |<--{MCU, A}--| |-- {A,MARS}->| I'm not sure how MARS got into that flow. I hope you understand how that would happen now. Section 6 paragraph 3. PEJ: This is similar to the above, but again I don't know how/when/why A would suddenly change the "remote" value it sends in a flow like this. Why would A send a UUID that had never been part of these flows? Maybe it would have helped if I drew A as an intermediary initially. PEJ: I don't think it would make any difference. If the intermediary originated a UUID (e.g., the 3PCC case), it might send {Q} to the MCU and the MCU replies with {MCU,Q}. Later, a UA (D) is inserted and sends a message to the MCU. Messages might contain {D,MCU} or {D,E} (where "E" was a value the intermediary had previously used with D). Either of these things could happen. Section 9 needs to be recast explicitly as examples. It is very confusing to have things in examples labelled "Rules" or appear to be defining operation. New second paragraph in 9 that says this? "This section is for illustrative purposes only and is non-normative." That's not enough. Please don't be lazy. Change the text. PEJ: OK Section 9.2 should show a 100 Trying 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? Consider adding a variant of 9.2 that sends the REFER out-of-dialog - would such a thing have the same session-id or a different one? Given that an OOD REFER is not part of a session, then that should introduce a new Session-ID UUID, right? Are you sure? Your ability to correlate the INVITES in a transfer goes out the window if you make that OOD part of a different session. You might want to see if the definition I sent will allow you to treat the OOD refer as part of the same session, or be explicit that you are not providing the ability to correlate the messages in this case. PEJ: Good point. I think we would want that correlation. Paul ------=_NextPart_000_0BE1_01CE3595.39185BE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Robert,

 

Please see comments below (PEJ):

 

The text (probably =
somewhere in section 5 or very early in section =
6)
should be more forceful in =
pointing
out that the sense of the remote part of =
this identifier is treated
exactly the opposite in =
responses than
the related from and to tags. It's =
an ok decision for the group to make,
but unless =
you make it _extremely_
obvious, it's very likely =
that an implementer would reuse their =
"what
tag to I put in the To: of =
responses" =
logic.
 
How =
about this right at the end of the first paragraph in Section =
6?
 
"The UUID of =
the sender of the message MUST appear first in the =
Session-ID
header and the UUID of the peer device, =
if known, must appear as the
"remote" =
parameter following the sender's UUID."

You missed the important part of my point. The issue = is that you are treating
the session-id differently in _responses_ = than SIP treats to and from tags in
responses.

 

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?

 
Section 6 needs to =
make it clear what an intermediary sending =
a
hop-by-hop SIP message (such as a 100 =
trying,
or a CANCEL) must or must not include for a =
Session-ID. I noted that
after the end of the =
second paragraph - maybe
that's a good place for =
the =
discussion?
 
Section 7 is intended to discuss intermediary behavior and it = says
intermediaries must not alter the UUID =
values.  Whether it adds them or not
should be =
optional and that is also covered in Section 7.  So, what =
is
missing, exactly?

Proxies _source_ 100 Tryings and CANCELs. They don't = forward them.
Point to me where you think explaining what to put in = either a 100 Trying
or a Cancel is in the current text. I assert that = you have not covered either
message (or any other hop-by-hop message, = such as an ACK to a non-200
final response to an INVITE).

 

PEJ: Ah, yes… now that point I missed.  You’re correct = that this is not presently addressed.  What confused me was that = you were in Section 6, but this should be a topic of Section = 7.



I suspect you are = wanting to copy the logic that 3261 uses for populating
the To and = >From headers (specifically the tags) for those messages (except
for = reversing the sense of what's remote in responses as above). But = the
document currently does not say that.

 

PEJ: For 100 Trying, the proxy would not be in a position to offer = either UUID, unless it just fabricated a bogus value.  We could do = that, but is there value in doing so?  A CANCEL could have = valid values if the intermediary maintains state information (as shown = in in your example below).  I think we need suggestions on what to = do here.  I would hope this guidance could go into Section = 7.



A couple of quick = examples here. You need to draw more in the document.

(using S: = as a shorthand for Session ID, and the {A}, {A,B}, {B,A} notation from = the draft.)

View this in a fixed width font
 A          = Proxy           &n= bsp; B1           = B2
 | Inv        = |            =    = |            = |
 | S: {A}     = |            =    = |            = = |
 |----------->|       &nb= sp;       = |            = = |
 |          &= nbsp; | Inv           = |            = = |
 |          &= nbsp; | S: {A}        = |            = = |
 |          &= nbsp; = |-------------->|         = ;    = |
 |          &= nbsp; | Inv           = |            = = |
 |          &= nbsp; | S: {A}        = |            = = |
 |          &= nbsp; = |---------------------------->|
 |    &nbs= p;       | 603 Decline   = |            = = |
 |          &= nbsp; | S: {B1,A}     = |            = = |
 |          &= nbsp; = |<--------------|         = ;    = |
 |          &= nbsp; | ACK           = |            = = |
 |          &= nbsp; | S: {A,B1}     = |            = = |
 |          &= nbsp; = |-------------->|         = ;    = |
 |          &= nbsp; | CANCEL        = |            = |
 | 603 Decline| S: = {A}        = |            = |
 | S: {B1,A}  = |---------------------------->|      &nb= sp;     
 |<-----------| 200 OK (to = the CANCEL)      |
 | = ACK        | S: = {B2,A}     = |            = |
 | S: {A,B1}  = |<----------------------------|
 |----------->| 487 = Request Cancelled       = |
 |          &= nbsp; | S: = {B2,A}           &= nbsp;       = |
 |          &= nbsp; = |<----------------------------|
 |    &nbs= p;       | = ACK           &nbs= p;            = ; | =
 |          &n= bsp; | S: = {A,B2}           &= nbsp;       = |
 |          &= nbsp; |---------------------------->|

I am _guessing_ = at what you intended to be in that CANCEL and its 200 OK,
and in the = hop-by-hop ACKs. Did I guess correctly? What if B2 were another
proxy = - would it make up a B2 to put in the 200 OK to that cancel?

 

PEJ: I’m inclined to  say that a proxy initiating or = replying to such messages should not include a Session-ID if it does not = know what the endpoint UUIDs are. But, as I said, I’m open to = input on this one.  I don’t know what the most appropriate = thing is to do.



The = text needs to be clear about these things. =             &= nbsp;           &n= bsp;           &nb= sp;     

PEJ: Agreed.  I don’t think it was considered = before.

Section 6 paragraph =
3 is out of place - it breaks the flow of =
the
endpoint behavior section. I suspect it =
needs
a section of its own, and it needs to say =
more.
 
I =
think the paragraph is in the right place, because we're still =
talking
about Bob here.  I think what's =
confusing is the use of the =
words
"non-intermediary UAS".  We're =
talking about Bob, but there was a request to
make =
the point that we're not talking about intermediaries when we speak =
of
this section.  If we replace =
"non-intermediary UAS" with "UA", would =
this
sound better?

Uh, no. I'm talking about the paragraph that = says

   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.

You appear to be talking = about paragraph 2, not paragraph 3.

PEJ: OK.  That particular paragraph is then followed by a = paragraph that is related.  So, if we move that, we need to move = the next.  Actually, this whole section has undergone a bit of = revision.  I’ll post the text to the list separately and = let’s work on the organization and wording. = ;-)

 
 
If a UA gets a =
remote
parameter that does not match what it =
thought
it was, should it start _using_ the =
parameter value it received in any
subsequent =
messages it sends, or should it stick
with what it =
thought it's end was supposed to be? I'm assuming =
the
latter, given paragraph 5 (which I think =
should
also be moved along with paragraph 3. Either =
way, the text needs to =
be
explicit.
=
 
The "remote" parameter that Alice would =
receive in a message is her UUID.
If it's wrong, =
she should ignore it.

Where does = the document say that that Alice would ignore it?
Again, I'm talking = about that third paragraph of section 6 that I quote above.
This is = the "Martian" that I talk about below as well. Something = sent
a message to Alice containing a remote parameter that _should_ = have been
what Alice provided, but it wasn't. All you say is that = Alice shouldn't treat that
as an error. You don't say (yet) that she = should ignore it. If that's what should
happen you should go further = and say endpoints should never even look at what
they receive an the = remote parameter.

 

PEJ: I agree with your last statement: Alice should never even consider = the “remote” parameter, as it’s useless to her.  = However, we had a discussion on this point and folks said that Alice = might want to log it.  So, I unless folks want to retract the view, = I can’t write that she should ignore it.  That’s text = that is in my version, but not yet published.  That will be in the = text I send to the list shortly.  Let’s consider that and = further refine it.

 
 
I think your question is if Bob receives one =
"local-UUID" value in an INVITE
and 20 =
minutes later there is a new INVITE for the same call with =
a
different "local-UUID" value, which =
value should Bob use in subsequent
messages?  =
The answer would be the most recently received =
"local-UUID"
value.

That was absolutely not my question.
I hope you = have it now from what's above, but I'll be graphic:
What section 6 = paragraph 3 says is that this can happen to Alice:
(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)
  |<--------|

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).  Then she received a message from B to her, but this time = mislabeled.  I don’t see how that can happen.  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.

Section 8 first =
paragraph: What happens if the MCU gets one of the =
alien
UUIDs mentioned in =
section 6 paragraph 3?
 
The MCU is only =
interested in the "local-UUID" field.  It would not get =
an
alien value there. =

I'm sorry - there may = be service interactions in processing a request it sends,
and the = response it gets has a Q in it, just like above.  The fix you are = working
towards will handle this = case.

Wouldn't it miss =
such a message since it wouldn't have the UUID the =
MCU
had created in it? Or are you expecting you =
would
find it through a chain of association with =
whatever happened at the
endpoint that sent the =
martian?
 
A  &n=
bsp;           &nb=
sp;     MCU
|<--  {MCU} =
-- |
|--- =
{A,MCU}->|
|<--{MCU, =
A}--|
|-- =
{A,MARS}->|
 
<= pre>I'm not sure how MARS got into that flow.

I hope you understand how that would happen now. = Section 6 paragraph 3.

 

PEJ: This is similar to the above, but again I don’t know = how/when/why A would suddenly change the “remote” value it = sends in a flow like this.



  Why would A send a =
UUID that had
never been part of these =
flows?

Maybe it would have helped = if I drew A as an intermediary initially.

PEJ: I don’t think it would make any difference.  If the = intermediary originated a UUID (e.g., the 3PCC case), it might send {Q} = to the MCU and the MCU replies with {MCU,Q}.  Later, a UA (D) is = inserted and sends a message to the MCU.  Messages might contain = {D,MCU} or {D,E} (where “E” was a value the intermediary had = previously used with D).  Either of these things could = happen.

 
Section 9 needs to =
be recast explicitly as examples. It is =
very
confusing to have things in examples labelled =
"Rules" or appear
to be defining =
operation.
 
=
New second paragraph in 9 that says =
this?
"This section is for illustrative =
purposes only and is non-normative."

That's not enough. Please don't be lazy. Change the = text.

PEJ: =
OK
 
Section 9.2 should =
show a 100 =
Trying
 
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?

 
 =

Consider adding a =
variant of 9.2 that sends the REFER out-of-dialog =
-
would such a thing have the same session-id or a =
different =
one?
 
Given =
that an OOD REFER is not part of a session,
 then that should =
introduce
a new Session-ID UUID, =
right?

Are you sure? = Your ability to correlate the INVITES in a transfer goes out the = window
if you make that OOD part of a different session. You might = want to see if the
definition I sent will allow you to treat the OOD = refer as part of the same session,
or be explicit that you are not = providing the ability to correlate the messages in this = case.

PEJ: Good point.  I think we would want that = correlation.

 

Paul

------=_NextPart_000_0BE1_01CE3595.39185BE0-- From paulej@packetizer.com Tue Apr 9 23:49:37 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFBC21F8F17 for ; Tue, 9 Apr 2013 23:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DKSE5cy1hWG for ; Tue, 9 Apr 2013 23:49:37 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E6DCD21F8EFD for ; Tue, 9 Apr 2013 23:49:36 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r3A6nZi8020864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 10 Apr 2013 02:49:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1365576576; bh=trJ+qHzD9PmoNEF/J7gA7mzH/1p3RKgG3anNCa3JTsw=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=nXQGUt6zCRuE8ML3MhzetgBmMUmWHTmcC6GncMFXp4XdwnZ7iuNtaNMKrU6ktWWdn IbowgnNp04hH1aDKY934HWlF2L/v4xgoUXqcjvTnw33v7mgxlpBnQOBD1NAgtc2/Nc P5LZsXX6KNZyXepEdqbedbJwZ+pHhlOmcx6XIyTc= From: "Paul E. Jones" To: Date: Wed, 10 Apr 2013 02:49:41 -0400 Message-ID: <0bed01ce35b7$94840390$bd8c0ab0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac41ttuZWDg0pVruScaj482kAkOwRw== Content-Language: en-us Subject: [Insipid] Endpoint Behavior X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 06:49:37 -0000 Folks, Below is what I presently have in Section 6 ("Endpoint Behavior") of the draft. Please suggest how we should move things or split things to improve clarity. Suggested wording changes are welcome, of course. Paul ------------------------- 6. Endpoint Behavior To comply with this specification, SIP UAs MUST include a Session-ID header-value in all SIP messages transmitted as a part of a communication session. The UUID of the sender of the message MUST appear first in the Session-ID header and the UUID of the peer device, if known, must appear as the "remote" parameter following the sender's UUID. Once a UA allocates a UUID value for a communication session, the UA MUST NOT change that UUID value for the duration of the session, including when - communication attempts are retried due to receipt of 4xx messages; - the session is redirected in response to a 3xx message; or - a session is transferred via a REFER message [RFC3515], or when a SIP dialog is replaced via an INVITE with Replaces [RFC3891]. A non-intermediary UAS UA that receives a Session-ID header MUST take note of the first UUID value (i.e., the "local-UUID") that it receives in the Session-ID header and assume that that is the UUID of the peer endpoint within that communications session. UAs MUST include this received UUID value as the "remote" parameter when transmitting subsequent messages. It should be noted that messages received by a UA might contain a "remote" parameter that does not match the UAs UUID. This might happen as a result of service interactions by intermediaries and MUST NOT negatively affect the communication session. However, the UA may log this event for the purposes of troubleshooting. For any purpose the UA has for the Session-ID, it MUST assume that the Session-ID is {A,B} where "A" is the UUID value of this endpoint and "B" is the UUID value of the peer endpoint, taken from the most recently received message within this session. An endpoint MUST assume that the UUID value of the peer UA MAY change at any time due to service interactions. If the UUID value of the peer UA changes, the UA MUST include this new UUID as the "remote" parameter in any subsequent messages. It is also important to note that if a session is forked by an intermediary in the network, the initiating UA may receive multiple responses back from different endpoints, each of which will contain a different UUID value. UAs MUST take care to ensure that the correct UUID value is returned in the "remote" parameter when responding to those endpoints. From rjsparks@nostrum.com Wed Apr 10 07:25:49 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D391821F981C for ; Wed, 10 Apr 2013 07:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUnXPvZzKkHk for ; Wed, 10 Apr 2013 07:25:47 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 265E721F9628 for ; Wed, 10 Apr 2013 07:25:45 -0700 (PDT) Received: from unnumerable.tekelec.com ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3AEPhtO087290 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Wed, 10 Apr 2013 09:25:43 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51657669.2090701@nostrum.com> Date: Wed, 10 Apr 2013 09:25:45 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Paul E. Jones" References: <515C9D18.706@nostrum.com> <0b5b01ce3573$20f1c5f0$62d551d0$@packetizer.com> <5164ABE5.9010602@nostrum.com> <0be001ce35b6$c026eea0$4074cbe0$@packetizer.com> In-Reply-To: <0be001ce35b6$c026eea0$4074cbe0$@packetizer.com> Content-Type: multipart/alternative; boundary="------------060206000204030509020306" Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: insipid@ietf.org Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-00 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 14:25:50 -0000 This is a multi-part message in MIME format. --------------060206000204030509020306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 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. --------------060206000204030509020306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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.

--------------060206000204030509020306-- From eckelcu@cisco.com Fri Apr 12 12:20:53 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035DB21F8EA7 for ; Fri, 12 Apr 2013 12:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APkaZhYnUChj for ; Fri, 12 Apr 2013 12:20:51 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 777C821F8E79 for ; Fri, 12 Apr 2013 12:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2255; q=dns/txt; s=iport; t=1365794451; x=1367004051; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3GByyQXaeV8eMilz61YZ3iUTeSjUvegweBV3CxxWfh4=; b=Q7z+wopyIdwFvBGa/oleQS0wYqTTDCPfgbb+vlofxgVTXI8Ns6HiB/fS te4UMPQ0vl4IWx2wFbtWMTIqKU6wVGwIXWklFDs5bQgfLBwkN1tU4PwCh VaAlo0CGj26p6iB1tU1oCXqxRPjxjvTi9wZwVHqOKS5otU3w7J3ljZkww k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFACleaFGtJV2b/2dsb2JhbABQgwbCGYEMFnSCHwEBAQMBOi4WBwQCAQgRBAEBCxQJBzIUCQgBAQQBEgiIBgUBvQeOZjgGglphA6gTgwuCKA X-IronPort-AV: E=Sophos;i="4.87,464,1363132800"; d="scan'208";a="198180657" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 12 Apr 2013 19:20:46 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3CJKkcg022375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Apr 2013 19:20:46 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.12]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 12 Apr 2013 14:20:46 -0500 From: "Charles Eckel (eckelcu)" To: "Paul E. Jones" , "'Brett Tate'" , "James Polk (jmpolk)" , "insipid@ietf.org" Thread-Topic: [Insipid] disaggregated media: call origination Thread-Index: Ac4smvCDkRVJESN5T7qqv8kqRFB4yQACobgsAA8wsIAACgwnMAIgKyuAAInFhzA= Date: Fri, 12 Apr 2013 19:20:45 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047FB411@xmb-aln-x08.cisco.com> References: <576A8B541C219D4E9CEB1DF8C19C7B88196A55D1@MBX07.citservers.local> <201303291747.r2THlHFO006920@rcdn-core2-1.cisco.com> <576A8B541C219D4E9CEB1DF8C19C7B88196A5629@MBX07.citservers.local> <92B7E61ADAC1BB4F941F943788C08828047DF088@xmb-aln-x08.cisco.com> <0b4401ce3561$2f423110$8dc69330$@packetizer.com> In-Reply-To: <0b4401ce3561$2f423110$8dc69330$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] disaggregated media: call origination X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 19:20:53 -0000 Hi Paul, I see the distinction you are making and I am fine with it. I agree that id= eally a B2BUA should pass the UUIDs along transparently. I cases in which t= his is not possible, such as the disaggregated media case and the conferenc= e server case, we want the B2BUA/conference server to consistently use the = same half key for itself. Cheers, Charles -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com]=20 Sent: Tuesday, April 09, 2013 1:31 PM To: Charles Eckel (eckelcu); 'Brett Tate'; James Polk (jmpolk); insipid@iet= f.org Subject: RE: [Insipid] disaggregated media: call origination Charles, > Perhaps this requirement needs be to expanded a bit to differentiate > between proxies and B2BUA. For a proxy, in think the existing wording of > Req 3 is fine. For a B2BUA, the requirement needs to be changed to state > that 'M', in this example, remains unchanged rather than the entire > identifier remains unchanged. I don't think it's a matter of B2BUA vs. Proxy. We want both to pass the UUIDs along transparently. However, the disaggregated media flow is a special case because the B2BUA i= s acting like a gateway. Basically, it's fully-terminating the SIP signaling and originating new calls to both Bob's computer (Bc) and phone (Bp). In the flow Brett originally presented and the flow that James drew up, it appeared to me that the B2BUA received a call from Alice, then initiated communication with Bc and Bp. Perhaps the "From" header going to both devices still said "Alice". Perhap= s the Call-ID was the same, too. However, if Bob's phone and computer answered, what "tag" does the B2BUA send back to Alice? Something Bc returned or something Bp returned? Or something entirely different? The B2BUA has to make a choice. As far as we could see, this call flow looked like a conference call where the B2BUA was acting like a PBX/MCU/other. It was "terminating" the call from Alice and then inviting Bp and Bc into the conference. Media would go directly from Bp and Bc to Alice, perhaps, but it was clear that the B2BUA was playing tricks with the signaling. So, the call flow James prepared tried to address this special case. Paul From paulej@packetizer.com Thu Apr 18 09:57:51 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345AA21F905A for ; Thu, 18 Apr 2013 09:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhYmWz+Rercf for ; Thu, 18 Apr 2013 09:57:47 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0E82321F8FF8 for ; Thu, 18 Apr 2013 09:57:46 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r3IGvjER013311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Apr 2013 12:57:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1366304266; bh=p1QAechAE3LjgGW/YWp3FdIUkvIBctAHDmJYUxLPpHI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=BhzXSmUvXKAQI07co+qP3CXafp9Gva8EziQGcvRRflGj2AstMqeOGBXNIP4q4IT+Z RjBQIUmUChCJc5SRROniZl92I6wwouSLR/UCcpgPhGJ38qsPlytE65U5DFIH18BsvO 3rpDrWVK211YK3vPoBvftab7JVSDGKfg5ZR31JFc= From: "Paul E. Jones" To: "'Robert Sparks'" References: <515C9D18.706@nostrum.com> <0b5b01ce3573$20f1c5f0$62d551d0$@packetizer.com> <5164ABE5.9010602@nostrum.com> <0be001ce35b6$c026eea0$4074cbe0$@packetizer.com> <51657669.2090701@nostrum.com> In-Reply-To: <51657669.2090701@nostrum.com> Date: Thu, 18 Apr 2013 12:57:55 -0400 Message-ID: <011801ce3c55$df47bb70$9dd73250$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0119_01CE3C34.583753F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+Gwhq2SbtlOTSELR/UdBeheRutQLdSoPaAmz9fRoBvJmg7QKhMQ0AmC8qOsA= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-00 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 16:57:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0119_01CE3C34.583753F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Robert, Comments below (PEJ): From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: Wednesday, April 10, 2013 10:26 AM To: Paul E. Jones Cc: insipid@ietf.org Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-00 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. PEJ: I'm still struggling with this language. The example mentions two headers, whereas we're dealing with a single header. This is more like the Max-Forwards header, which is set by the sender. How about this: Note that the "sender" of the message is not the user agent that initiates a transaction. Rather, the "sender" is the user agent initially transmits a message, regardless of whether this is a new transaction or a response to a message received. I just tried to clarify what "sender" means. But, this might also need wordsmithing. How close is this? 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, }. 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. PEJ: Thinking about this further, I suppose it could happen, so we need to allow for it. A B2BU in the middle might attempt to transfer B to M. That might fail or the "call leg" is transitioned back to A for good cause. As examples here, B might be directed to a music-on-hold server or a transfer attempted that fails (and transitions back). 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. PEJ: Given my revised position that this could be valid signaling, are you OK with the text? 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. PEJ: If the called endpoint sends a 100 (for whatever reason), I would expect the Session-ID to be present. The concern is with intermediaries. Those are more likely to generate a 100, but they are not the called endpoint. We could specify that the intermediaries generate a bogus UUID value, but what value is that? Should we specify that the intermediaries return a Session-ID with a UUID of zero and insert the "remote" parameter. Whatever folks want, I think we can discuss this explicitly in Section 7. Paul ------=_NextPart_000_0119_01CE3C34.583753F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Robert,

 

Comments below (PEJ):

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: = Wednesday, April 10, 2013 10:26 AM
To: Paul E. = Jones
Cc: insipid@ietf.org
Subject: Re: [Insipid] = Comments on = draft-ietf-insipid-session-id-00

 

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.

 

PEJ: I’m still struggling with this language.  The example = mentions two headers, whereas we’re dealing with a single = header.  This is more like the Max-Forwards header, which is set by = the sender.  How about this:

 

Note that the “sender” of the message is not the user = agent that initiates a transaction.  Rather, the = “sender” is the user agent initially transmits a message, = regardless of whether this is a new transaction or a response to a = message received.

 

I just tried to clarify what “sender” means.  But, = this might also need wordsmithing.  How close is = this?

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.

PEJ: Thinking about this further, I suppose it could happen, = so we need to allow for it.  A B2BU in the middle might attempt to = transfer B to M.  That might fail or the “call leg” is = transitioned back to A for good cause.  As examples here, B might = be directed to a music-on-hold server or a transfer attempted that fails = (and transitions back).



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.

 

PEJ: Given my revised position that this could be valid signaling, = are you OK with the text?

 

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.

PEJ: If the called endpoint sends a 100 (for whatever reason), I = would expect the Session-ID to be present.  The concern is with = intermediaries.  Those are more likely to generate a 100, but they = are not the called endpoint.  We could specify that the = intermediaries generate a bogus UUID value, but what value is = that?  Should we specify that the intermediaries return a = Session-ID with a UUID of zero and insert the “remote” = parameter.  Whatever folks want, I think we can discuss this = explicitly in Section 7.

Paul

------=_NextPart_000_0119_01CE3C34.583753F0--