Subject: Re: [Insipid] Communication Session

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 17 Dec 2012 20:48:42 +0000

Hi Paul,

How about we keep the name communication-session , but expand on the definition to incorporate my proposal? For example:

In this document, the word "session" refers to a "communication session" that may exist between two SIP user agents and that may pass through one or more intermediary devices, including B2BUAs or SIP Proxies. A communication session consists of one of more SIP transactions. A very simple communication session may be a single out-of-dialog SIP transaction (e.g. MESSAGE/200). In the case of a SIP dialog, the SIP message exchange includes a dialog creating INVITE transaction, and  zero of more subsequent SIP transactions within the same dialog (e.g. ACK, re-INVITE, BYE). Due to the existence of middle boxes, there may be multiple related SIP transactions or dialogs chained together along the path from one end of the communication session to the other. For example:

A -------middlebox--------B
SIP trans1 -----> SIP trans 2
SIP dialog 1 ---> SIP dialog 2

In such cases, the two SIP transactions or dialogs are part of a single communication session.

Cheers,
Charles

> -----Original Message-----
> From: Paul E. Jones [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2012 10:49 PM
> To: [email-masked]
> Cc: Charles Eckel (eckelcu)
> Subject: Communication Session
> 
> Folks,
> 
> 
> 
> I said I will publish a new revision of the requirements document.  I have a
> list of things on my list, but I may have neglected a few items.  If you can
> think of an important change you wanted made to the requirements draft,
> let me know.
> 
> 
> 
> One thing that was discussed and for which I don't have an answer is that of
> "communication session" vs. something else.  The requirements document
> currently says:
> 
> 
> 
> In this document, the word "session" refers to a "communication session"
> that may exist between two SIP user agents or that might pass through one
> or more intermediary devices, including B2BUAs or SIP Proxies.
> 
> 
> 
> The term "end-to-end" in this document means the communication session
> from the point of origin, passing through any number of intermediaries, to
> the ultimate point of termination. It is recognized that legacy devices may
> not support the "end-to-end" session identifier, though an identifier might
> be created by an intermediary when it is absent from the session signaling.
> 
> 
> 
> There was a desire for changes in terminology.  Specifically what, though?
> Please look at the terminology in the current draft and let's discuss what
> changes to make:
> 
> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-02
> 
> 
> 
> I'm not so confident that we'll have a quick answer, so what I might do is go
> ahead and publish an -03 with what other changes I believe folks wanted
> (and any I get between now and tomorrow evening).  Don't take that
> publication as ignoring this point.  We can work on revising the terminology
> even after the next version.
> 
> 
> 
> Charles Eckel proposed (on Nov. 3) to replace the words "communication
> session" with "SIP message exchange".  Paul Kyzivat seemed to think that
> might work, but I didn't see others comment.  Looking at the proposal, I'm
> having trouble seeing how I'd use the term in these sentences:
> 
> *         "The identifier is intended to represents an end-to-end
> communication session from the originating device to the terminating
> device"
> 
> *         "if a PBX joins or merges two communication sessions together locally,
> the end-to-end properties of currently-defined identifiers are lost"
> 
> *         "we need the ability to identify each communication session through a
> single SIP header-value regardless of which type of SIP servers"
> 
> *         "A communication session might originate in an H.323 endpoint and
> pass through a Session Border Controller before ultimately reaching a
> terminating SIP user agent"
> 
> *         Etc.
> 
> 
> 
> The sentence with H.323 mentioned is a bit tricky and extends the term to
> non-SIP signaling.  Still, we do want to cover that case and the intent
> certainly was that a "communication session" is one that s
> 
> 
> 
> Personally, I like the term "communication session", but perhaps we just
> need to modify it along the lines of what Charles suggested?  Can folks offer
> a good replacement definition to put in Section 2?
> 
> 
> 
> Paul
> 
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 17 Dec 2012 22:41:30 -0500

Charles,

This sounds great to me.  Do others like this?

What about the following paragraph?

The term "end-to-end" in this document means the communication session from
the point of origin, passing through any number of intermediaries, to the
ultimate point of termination. It is recognized that legacy devices may not
support the "end-to-end" session identifier, though an identifier might be
created by an intermediary when it is absent from the session signaling.

Paul

> From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> Sent: Monday, December 17, 2012 3:49 PM
> To: Paul E. Jones; [email-masked]
> Subject: RE: Communication Session
> 
> Hi Paul,
> 
> How about we keep the name communication-session , but expand on the
> definition to incorporate my proposal? For example:
> 
> that may exist between two SIP user agents and that may pass through one
> or more intermediary devices, including B2BUAs or SIP Proxies. A
> communication session consists of one of more SIP transactions. A very
> simple communication session may be a single out-of-dialog SIP
> transaction (e.g. MESSAGE/200). In the case of a SIP dialog, the SIP
> message exchange includes a dialog creating INVITE transaction, and
> zero of more subsequent SIP transactions within the same dialog (e.g.
> ACK, re-INVITE, BYE). Due to the existence of middle boxes, there may be
> multiple related SIP transactions or dialogs chained together along the
> path from one end of the communication session to the other. For example:
> 
> > I said I will publish a new revision of the requirements document.  I
> > have a list of things on my list, but I may have neglected a few
> > items.  If you can think of an important change you wanted made to the
> > requirements draft, let me know.
> >
> >
> >
> > One thing that was discussed and for which I don't have an answer is
> > that of "communication session" vs. something else.  The requirements
> > document currently says:
> >
> >
> >
> > that may exist between two SIP user agents or that might pass through
> > one or more intermediary devices, including B2BUAs or SIP Proxies.
> >
> >
> >
> > from the point of origin, passing through any number of
> > intermediaries, to the ultimate point of termination. It is recognized
> > that legacy devices may not support the "end-to-end" session
> > identifier, though an identifier might be created by an intermediary
> when it is absent from the session signaling.
> >
> >
> >
> > Please look at the terminology in the current draft and let's discuss
> > what changes to make:
> >
> > I'm not so confident that we'll have a quick answer, so what I might
> > do is go ahead and publish an -03 with what other changes I believe
> > folks wanted (and any I get between now and tomorrow evening).  Don't
> > take that publication as ignoring this point.  We can work on revising
> > the terminology even after the next version.
> >
> >
> >
> > session" with "SIP message exchange".  Paul Kyzivat seemed to think
> > that might work, but I didn't see others comment.  Looking at the
> > proposal, I'm having trouble seeing how I'd use the term in these
> sentences:
> >
> > The sentence with H.323 mentioned is a bit tricky and extends the term
> > to non-SIP signaling.  Still, we do want to cover that case and the
> > intent certainly was that a "communication session" is one that s
> >
> >
> >
> > Personally, I like the term "communication session", but perhaps we
> > just need to modify it along the lines of what Charles suggested?  Can
> > folks offer a good replacement definition to put in Section 2?
> >
> >
> >
> > Paul
> >
> >

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 18 Dec 2012 16:36:39 +0000

Hi Paul,

Your definition  for end-to-end looks okay to me.

Cheers,
Charles

> Sent: Monday, December 17, 2012 7:42 PM
> To: Charles Eckel (eckelcu); [email-masked]
> from