Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid-session-id

From: James Polk <[email-masked]>
Date: Sun, 04 Nov 2012 22:13:33 -0600

At 03:38 PM 10/26/2012, Paul Kyzivat wrote:
>Here are some things I found while reviewing the latest version:
>
>Section 4:
>
>    The Session Identifier is comprised of two RFC 4122 defined UUIDs
>    [4], with each UUID created by the endpoints participating in the
>    session.
>
>The above isn't correct when the id is inserted by an intermediary. 
>I think it might be more correct to say:
>
>    The Session Identifier is comprised of two RFC 4122 defined UUIDs
>    [4], with each UUID representing one of the endpoints participating
>    in the session.
>
>Section 5:
>
>    The "sess-id" value represents the UUID value of the UA transmitting
>    the message.  If the UA transmitting the message previously received
>    a UUID value from its peer endpoint, it MUST include that UUID as the
>    "rcvr" parameter.
>
>I gather this means that the sess-id and rcvr-uuid need to be 
>swapped in the response to a request. That seems a little odd. It 
>runs contrary to how most things work in responses. But apparently 
>it is fundamental to the usage rules.
>
>Section 6:
>
>    ... Session-ID header-values MUST NOT be present in any other
>    SIP header than the Session-ID header.
>
>Why is it important to mandate this?
>
>    UAs MUST ignore the value in the "rcvr" parameter in any message it
>    receives, as this value may be incorrect due to service interactions
>    as shown in examples later in this document.
>
>If it is entirely ignored, then there is no point in sending it. For 
>instance, wouldn't you want to include it when logging? (Even if the 
>log also includes the local UUID.) Presumably an inconsistency 
>between these values may itself be interesting and worth noting. But 
>it can't be noted if the value in the message is ignored.
>
>I'm guessing that you mean that the recipient should not be 
>concerned if the value received is inconsistent with the value it is 
>holding in local state, and should not replace its local value with 
>the one received.
>
>Section 7:
>
>    If performing interworking between SIP and another session protocol,
>    an intermediary MUST convert the Session-ID header as necessary so
>    that it properly places the correct UUID value of the message
>    transmitter and assumed recipient. This is a protocol gateway or
>    interworking function.
>
>The above is only possible if the other protocol has a comparable 
>mechanism in which the value can be represented. Any normative 
>behavior should be specified as part of the interworking 
>specification, not here.
>
>Section 8:
>
>    Note, however, that this assumption of being part of the same
>    conference is not always true.  For example, in a SIP forking
>    scenario, there might also be what appears to be multiple sessions
>    with a shared UUID value.  This is actually desirable.  What is
>    desired is to allow for the association of related sessions.  Whether
>    sessions are related because of forking or because endpoints are
>    communicating as a part of a conference does not matter.  They are
>    nonetheless related.
>
>So, when two sessions have half of a session id in common they are 
>"related", somehow. Then I might be encouraged to reuse my half when 
>initiating distinct sessions that I want to be treated as "related". 
>For instance, if I send a sequence of MESSAGE requests to the same 
>recipient, and I think they are related, maybe I'll be inclined to 
>use the same uuid in them?

Paul J answered each of the above, and he's been nice enough to 
volunteer me to answer each of the below.

>Section 10.2:
>
>The re-INVITE usage in this example seems entirely spurious. The 
>sequence starting with the REFER stands on its own. The bullet:
>
>      o UA-Bob reINVITEs Alice to call Carol, using a REFER transaction,
>        as described in [RFC3515]. UA-Alice is initially put on hold,
>        then told in the REFER who to contact with a new INVITE, in this
>        case UA-Carol.
>
>makes no sense to me.

I understand your confusion, the bullets aren't to be read literally 
as SIP messages, but more of a 'here's what's happening' pov. This 
will be cleaned up.

Technically, when invoking a call transfer using REFER, Bob would 
reINVITE Alice to audio=send-only, and once that transaction was 
completed, Bob would send a REFER directing Alice to INVITE Carol to 
a session at Bob's request.

>Section 10.3:
>
>This also makes no sense to me as a stand-alone example. How is it 
>that Bob decides to do a re-INVITE if he wants to transfer to Bob? 
>How is it that the B2BUA knows it should call Carol? And the BYE 
>from the B2BUA to Alice means that the call to Carol will no longer 
>be functional.

Many B2BUA's acting as enterprise call controllers (i.e., IP-PBXs) 
move part of an established end-to-end call when someone is 
transferred to another UA. You mentioning how this isn't propagated 
to Alice is how his occurs.

>It is possible to construct a hybrid of what is shown in 10.2 and 
>10.3, where the REFER is terminated by the B2BUA, and not propagated 
>to Alice. Instead, the B2BUA uses a re-INVITE to Alice to update her 
>with the session info to Carol.
>
>Secton 10.4:
>
>This all seems reasonable. But it assumes that correlating that all 
>the sessions are part of the same conference is more important than 
>correlating the initial callin to the conference server with the 
>portion after logging in to the particular conference.

Not true. Alice sends UUID A to the focus, which answers back with 
UUID M1. That M1 goes away doesn't matter because UID A did not, 
therefore a log, trace, whatever on that call would turn up any 
related sessions that had UUID A and consider them part of the same call.

>The conference focus is in control of this, based on whether it 
>switches to a common uuid or not. That is fine if it is the 
>appropriate entity to make that decision. Not so good for somebody 
>trying to trace problems that require continuity for the entire call 
>of one participant.
>
>Section 10.6:
>
>Shouldn't the ACK from the B2BUA to Alice have {B,A} ???

oops, sorry about that

James

>         Thanks,
>         Paul
>
>
>On 10/25/12 8:45 PM, James Polk wrote:
>>Here is a list of the changes between the -00 and -01 versions of
>>draft-jones-insipid-session-id, for those that have not read this draft
>>yet:
>>
>>- Rewrote a lot of the text (see the diff URL listed below as proof),
>>but did not change the overall layout of the sections much, other than
>>adding the new sections mentioned below.
>>
>>- clarified how the Session-ID is constructed exactly.
>>
>>- changed the ABNF (thanks to Paul K for the help) but did not alter the
>>basic concept of two UUIDs (sender and receiver each insert their UUID)
>>to construct the Session-ID.
>>
>>- Added a new section on the 6 different call flow scenarios this
>>document solves for, covering
>>
>>    - Basic Session-ID Construction with 2 UUIDs
>>    - Basic Call Transfer using REFER
>>    - Basic Call Transfer using reINVITE
>>    - Single Focus Conferencing
>>    - Single Focus Conferencing using WebEx
>>    - Basic 3PCC for two UAs
>>
>>each call flow shows the values of the UUIDs that make up the Session-ID
>>on a per message basis (something that Robert asked for in the Vancouver
>>meeting).
>>
>>- decided against showing how to do a multiple focus conference call in
>>this version. That call flow could be added in the next version.
>>
>>- Added a new section to includeda way to be mostly backwards compatible
>>with the "old way" of doing a session-id. It's not perfect, but attempts
>>to address each of the 4 scenarios:
>>
>>    - old calling old (should work fine)
>>    - new calling new (should work fine)
>>    - old calling new (interesting issues)
>>    - new calling old (more interesting issues)
>>
>>Comments and questions are encouraged
>>
>>James/Paul
>>
>>At 08:35 PM 10/22/2012, Paul E. Jones wrote:
>>>Folks,
>>>
>>>We've posted a revised version of the proposed solution for the
>>>end-to-end
>>>session identifier.
>>>
>>>This draft has been substantially revised and now includes a number of
>>>sample call flows.
>>>
>>>As we discussed during the interim calls, this version changes the
>>>syntax in
>>>an effort to try to make interworking with the current "Session-ID"
>>>header
>>>workable.
>>>
>>>Paul
>>>
>>> > -----Original Message-----
>>> > From: [email-masked] [mailto:i-d-announce-
>>> >> > [email-masked]] On Behalf Of [email-masked]
>>> > Sent: Monday, October 22, 2012 7:34 PM
>>> > To: [email-masked]
>>> > Subject: I-D Action: draft-jones-insipid-session-id-01.txt
>>> >
>>> >
>>> > A New Internet-Draft is available from the on-line Internet-Drafts
>>> > directories.
>>> >
>>> >
>>> >       Title           : End-to-End Session Identification in IP-Based
>>> > Multimedia Communication Networks
>>> >       Author(s)       : Paul E. Jones
>>> >                           Chris Pearce
>>> >                           James Polk
>>> >                           Gonzalo Salgueiro
>>> >       Filename        : draft-jones-insipid-session-id-01.txt
>>> >       Pages           : 17
>>> >       Date            : 2012-10-22
>>> >
>>> > Abstract:
>>> >    This document describes an end-to-end Session Identifier for use in
>>> >    IP-based Multimedia Communication systems that enables endpoints,
>>> >    intermediate devices, and management systems to identify a session
>>> >    end-to-end, associate multiple endpoints with a given multipoint
>>> >    conference, track communication sessions when they are redirected,
>>> >    and associate one or more media flows with a given communication
>>> >    session.
>>> >
>>> >
>>> > The IETF datatracker status page for this draft is:
>>> > https://datatracker.ietf.org/doc/draft-jones-insipid-session-id
>>> >
>>> > There's also a htmlized version available at:
>>> > http://tools.ietf.org/html/draft-jones-insipid-session-id-01
>>> >
>>> > A diff from the previous version is available at:
>>> > http://www.ietf.org/rfcdiff?url2=draft-jones-insipid-session-id-01
>>> >
>>> >
>>> > Internet-Drafts are also available by anonymous FTP at:
>>> > ftp://ftp.ietf.org/internet-drafts/
>>> >
>>> > _______________________________________________
>>> > I-D-Announce mailing list
>>> > [email-masked]
>>> > https://www.ietf.org/mailman/listinfo/i-d-announce
>>> > Internet-Draft directories: http://www.ietf.org/shadow.html or
>>> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>_______________________________________________
>>>insipid mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/insipid
>>
>>_______________________________________________
>>insipid mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/insipid
>
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: James Polk <[email-masked]>
Date: Sun, 04 Nov 2012 22:20:51 -0600

At 04:42 PM 10/26/2012, Paul E. Jones wrote:
>Paul,
> > The above isn't correct when the id is inserted by an intermediary. I
> > think it might be more correct to say:
> >
>Sounds good to me.  I'll make the change.
>
> > Section 5:
> >
> > I gather this means that the sess-id and rcvr-uuid need to be swapped in
> > the response to a request. That seems a little odd. It runs contrary to
> > how most things work in responses. But apparently it is fundamental to
> > the usage rules.
>
>Your interpretation is correct.  The sender of the message formulates the
>Session-ID header as specified.  However, how a header is set does vary.
>Some remain the same in an exchange, like CSeq.  Some get modified, like the
>"To" header with a tag added.  Others are set by the sender of the message,
>such as the Content-Length header.  Session-ID falls into the latter group.
>
> > Section 6:
> >

I just don't like this header-value showing up anywhere else that 
someone might not be looking for it and then wonder why things didn't 
work as planned. Similar constraint on Geolocation header-values.

>Good question.  I'm sure there was a rationale, but it is not apparent now.
>I'll remove it.

I'd like that you didn't, for the above reason.

James

> > instance, wouldn't you want to include it when logging? (Even if the log
> > also includes the local UUID.) Presumably an inconsistency between these
> > values may itself be interesting and worth noting. But it can't be noted
> > if the value in the message is ignored.
>
>We do want this value to be used by intermediaries, so they should not
>ignore it.  The reason I inserted this wording is that I do not want a UA to
>echo the value it receives back to the sender of that message in any
>subsequent message.
>
>Do you have a suggestion for wording that?
>
> > I'm guessing that you mean that the recipient should not be concerned if
> > the value received is inconsistent with the value it is holding in local
> > state, and should not replace its local value with the one received.
>
>Right.  If Carol (UUID=C) receives an INVITE that has "Session-ID:
>A;rcvr=B", we do not want Carol to panic because C is not there, but we also
>do not want Carol to echo back "Session-ID: B; rcvr=A".  Rather, we want
>Carol to form a reply like "Session-ID: C; rcvr=A".
>
> > Section 7:
> >
> > mechanism in which the value can be represented. Any normative behavior
> > should be specified as part of the interworking specification, not here.
>
>Is there more to say re: interworking than this?  I think there is one more
>sentence we should add:
>
>      If not suitable value exists, the intermediary may allocate a
>      UUID value to represent the endpoint for which it has no other
>      value.
>
>Sound reasonable?  If we move this, move it to where?  Introduce an
>interworking section only with this paragraph?
>
> > Section 8:
> >
> > initiating distinct sessions that I want to be treated as "related". For
> > instance, if I send a sequence of MESSAGE requests to the same recipient,
> > and I think they are related, maybe I'll be inclined to use the same
> > uuid in them?
>
>That we do not want.  Except in the case of a conference server, we want
>each UA to allocate a unique UUID for each session.
>
>Section 10.2 onward...  Let me allow James to respond on the call flows, as
>he provided that text. I don't want to put words in his mouth :-)
>
>Paul
>

---

From: James Polk <[email-masked]>
Date: Sun, 04 Nov 2012 22:32:49 -0600

At 12:48 PM 10/27/2012, Salvatore Loreto wrote:
>Hi there
>
>I have read the 01 and have the following questions
>

<snip>

>Example 10.5 is a little confused, as there Alice,Bob and Carol are 
>not just representation
>of their respective SIP UA, but more of their device that include 
>both an HTTP client + SIP UA
>
>In general I don't find any extra value in 10.5 comparing it to the 
>example in 10.4
>unless there is something protocol interworking between HTTP and SIP 
>that you want point out

Sal - Conferencing using Webex was something that was brought up 
during the last meeting (Vancouver) and I wasn't quick enough to 
track (when Hadriel talked about conferencing being taken out of the 
reqs ID because a lot of "higher than layer 7 stuff needs to happen 
to make that happen". Section 10.5 shows actually that there is no 
temporary UUIDs created for each UA when they call into a focus, that 
all of that is handled via an out of band web session to have the 
focus (Webex server) call the UA directly with the only UUID the 
webex server will need for everyone attending that webex conference. 
I'm not pushing Webex as a product here, just that it is something 
most (all?) of us are familiar with because we've used it ourselves, 
however frequently or infrequently.

James

>Cheers
>/Sal
>
>
>--
>Salvatore Loreto, PhD
><http://www.sloreto.com>www.sloreto.com
>
>
>On 10/26/12 3:45 AM, James Polk wrote:
>>draft-jones-insipid-session-id, for those that have not read this draft yet:
>>
>>- Rewrote a lot of the text (see the diff URL listed below as 
>>proof), but did not change the overall layout of the sections much, 
>>other than adding the new sections mentioned below.
>>
>>- changed the ABNF (thanks to Paul K for the help) but did not 
>>alter the basic concept of two UUIDs (sender and receiver each 
>>insert their UUID) to construct the Session-ID.
>>
>>each call flow shows the values of the UUIDs that make up the 
>>Session-ID on a per message basis (something that Robert asked for 
>>in the Vancouver meeting).
>>
>>- decided against showing how to do a multiple focus conference 
>>call in this version. That call flow could be added in the next version.
>>
>>- Added a new section to includeda way to be mostly backwards 
>>compatible with the "old way" of doing a session-id. It's not 
>>perfect, but attempts to address each of the 4 scenarios:
>>
>>>We've posted a revised version of the proposed solution for the end-to-end
>>>session identifier.
>>>
>>>an effort to try to make interworking with the current "Session-ID" header
>>>workable.
>>>
>>>Paul
>>>
>>> > From: 
>>> <mailto:[email-masked]>[email-masked] 
>>> g [<mailto:i-d-announce>mailto:i-d-announce-
>>> > <mailto:[email-masked]>[email-masked]] On Behalf Of 
>>> <mailto:[email-masked]>[email-masked]
>>> > To: <mailto:[email-masked]>[email-masked]
>>> <https://datatracker.ietf.org/doc/draft-jones-insipid-session-id>https://datatracker.ietf.org/doc/draft-jones-insipid-session-id 
>>>
>>> >
>>> <http://tools.ietf.org/html/draft-jones-insipid-session-id-01>http://tools.ietf.org/html/draft-jones-insipid-session-id-01 
>>>
>>> >
>>> <http://www.ietf.org/rfcdiff?url2=draft-jones-insipid-session-id-01>http://www.ietf.org/rfcdiff?url2=draft-jones-insipid-session-id-01 
>>>
>>> >
>>> >
>>> > <ftp://ftp.ietf.org/internet-drafts/>ftp://ftp.ietf.org/internet-drafts/
>>> >
>>> > <mailto:[email-masked]>[email-masked]
>>> > Internet-Draft directories: 
>>> <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html or
>>> > 
>>> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
>>>
>>>
>>><mailto:[email-masked]>[email-masked]
>><mailto:[email-masked]>[email-masked]

---

From: James Polk <[email-masked]>
Date: Sun, 04 Nov 2012 22:35:09 -0600

At 03:49 PM 10/27/2012, Paul E. Jones wrote:
> > > ignore it.  The reason I inserted this wording is that I do not want a
> > > UA to echo the value it receives back to the sender of that message in
> > > any subsequent message.
> > >
> > I think you already have normative language for what values should be
> > used. So the normative language here is redundant. I would recommend
> > replacing this with a Note giving warnings to implementers that
> > unexpected values might be seen.
>
>OK, I'll strike that.  How about this note:
>
>     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.
>
> > >> Section 7:
> > >>
> > > Is there more to say re: interworking than this?  I think there is one
> > > more sentence we should add:
> > >
> > ISTM that interworking can't be addressed in general. It must be
> > addressed case by case. If you want to discuss interworking with H.323,
> > then I think it would best be handled as a separate draft. If not that,
> > then at least a separate section in this draft focused explicitly on
> > that. (I think a separate draft because the community interested in it
> > is different. Many people interested in insipid won't be able to comment
> > meaningfully on this part.)
>
>OK, I'll delete it entirely.

are we really going to remove all mention of interworking between 
dissimilar call signaling protocols? Can we not at least have a 
non-normative comment or discussion about it. It is something that 
may not be obvious to someone else who just reads this one document.

James

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Nov 2012 22:24:52 -0500

On 11/4/12 11:35 PM, James Polk wrote:

> non-normative comment or discussion about it. It is something that may
> not be obvious to someone else who just reads this one document.

There was agreement to replace the RTCP reference in the requirements 
with something restricting the syntax & length of the ID so that it 
would also be suitable for use in other protocols. Some words about 
interworking can go there.

And then in the protocol document, perhaps in text describing the ABNF 
syntax, some similar words could appear.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 05 Nov 2012 22:32:33 -0500

Paul,

The wording on the suitability for RTCP is some text Ganzalo said he 
would work with me on in the requirements document.

The interworking text (between v0 and v1 endpoints) is entirely 
different and in the solution document.

Am I missing something?

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Nov 2012 00:19:01 +0000

On Nov 4, 2012, at 11:20 PM, James Polk <[email-masked]> wrote:

> I just don't like this header-value showing up anywhere else that someone might not be looking for it and then wonder why things didn't work as planned. Similar constraint on Geolocation header-values.

But we already know we might want it in another header, or at least a body: for SIPREC, for example, it might be put into a header or the XML metadata. (probably the latter, but it's not a big difference)

Also there's been some discussion of putting it in the Refer-To or Target header, though probably as an embedded Session-ID header inside the URI, so I guess we might weasel our way around any restriction against putting it in another header since we're keeping it in a Session-ID header but sticking that whole header into a URI somewhere else.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Nov 2012 12:10:14 +0000

Hi,

I agree with Hadriel.

In addition, each header field specification defines what values it can include. So, my suggestion is to remove the text.

IF we are going to allow the value in Refer-To/Target, even only as an embedded Session-ID header field inside a URI, you could write something like:

"This document also describes how the Session-ID header field can be embedded inside a URI or a Refer-To and Target header field."

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] on behalf of Hadriel Kaplan [[email-masked]]
Sent: Saturday, 10 November 2012 2:19 AM
To: James Polk
Cc: Paul E. Jones; <[email-masked]>; Paul Kyzivat
Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid-session-id

-hadriel