Subject: Re: [Insipid] Are we ready to LC on the requirements?

From: Robert Sparks <[email-masked]>
Date: Fri, 01 Mar 2013 14:17:48 -0600

On 2/24/13 8:38 AM, Paul E. Jones wrote:
> Paul,
>
> That still begs the question of "what language do we need to add or 
> change to make this clear?" In my mind, I know exactly what an 
> endpoint needs to do and what an SBC needs to do. But, I'll not say it 
> does not need more charity for those that do not have it clear in 
> their minds.
>
> But, perhaps being too close to the work, I'm having trouble seeing 
> where it is vague. Can you suggest text?
This is frustrating, for both of us probably. I've read the latest 
requirement document and it doesn't yet clearly
answer the questions I asked in the Atlanta meeting. I feel like I've 
asked them at several meetings before.
Can we stop that cycle of repeating the discussion by putting text in 
the document that directly answers each of these:

In a scenario where you only have one parallel forking SIP proxy, when 
an INVITE forks to two different
UAs and _both_ send 200 OKs, do you have one session or two? (This same 
question applies to early dialogs,
with or without early media, which is a _normal_ condition, not an race 
condition like multiple 200 OKs).

If you replace that with a _serial_ forking proxy, where you were in an 
early dialog with UA1, that got canceled
and then you ended up in an early dialog, and then a confirmed dialog 
with UA2, was that one session (with the
calling UA, UA1, and UA2 involved) or two sessions (one with the calling 
UA and UA1, the other with the calling
UA and UA2)?

If you replace that with a B2BUA that behaves similar to a serial 
forking proxy in that it only alerts one called thing
at a time, do you end up with one session or with two.

I don't see how the current document answers those questions. If I've 
missed that, please point to it and I'll see how
I can help make them more obvious.

Otherwise, can you please make the answers clear in the document, (not 
just in an email response).
>
> Paul
>
> ------------------------------------------------------------------------
> *From:* Paul Kyzivat <[email-masked]>
> *Sent:* Sun Feb 24 01:43:57 EST 2013
> *To:* "Paul E. Jones" <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Insipid] Are we ready to LC on the requirements?
>
> On 2/24/13 12:33 AM, Paul E. Jones wrote:
>
>     Paul, So what concept is vague? In terms of an H.323 device, I
>     would consider two terminals with users at each end to be a
>     communication session. I would consider a terminal and an MCU to
>     have a communication session. The collection of communication
>     sessions on an MCU to which one or more terrminals are a party is
>     a conference. And I would like to relate all those sessions by the
>     UUID the MCU uses in each of those sessions. That value could even
>     be the Conference ID in H.323. There are gateway devices that
>     connect to the PSTN that I would count as equal to a terminal.
>     But, there are gateway devices that bridge IP networks (SBCs) that
>     shoul! d just pass the UUIDs through. The difference between the
>     two really is whether it bridges an IPMC device to another or to
>     something else. There are call flows like the one you highlighted
>     in the threads where voice comes from one terminal and video from
>     another. That's an MCU, really. The session ID exists between
>     Alice and MCU (or PBX). The other devices Bob uses might share the
>     UUID of the MCU/PBX, but those are distinct communication sessions
>     like the typical MCU case. Yeah, such topologies do make it hard
>     to do debugging and the number of UUIDs makes it a pain, too, but
>     at least there is consistency in the assignments. So, it is
>     doable. So, how can we make progress here?
>
>
> We write some rules that any device that terminates more than one dialog
> can use to decide when one dialog should share a session-id with another
> dialog. The rules should get the "right" answer for all the use case!
>   s,
> and should be specific enough so that when applied to any device, no
> matter how weird, most reasonable people would agree with the answer.
> That way we can have a way of judging conformance to this specification.
>
> I realize this bridges the gap between what the requirements are
> responsible for and what the mechanism is responsible for. But the
> mechanism is about marking communications sessions, not defining them.
>
> OR I suppose the requirements could kick the can down the road, simply
> say that the mechanism must work for the specified use cases and itself
> must specify the algorithm for making the decision in other cases. But
> that just puts it off.
>
>   Thanks,
>   Paul K
>
>     Paul
>     ------------------------------------------------------------------------
>     *From:* Paul Kyzivat <[email-masked]> *Sent:* Sat F! eb 23
>     19:58:41 EST 2013 *To:* "Paul E. Jones" <[email-masked]>
>     *Cc:* [email-masked] *Subject:* Re: [Insipid] Are we ready to LC
>     on the requirements? On 2/21/13 9:51 PM, Paul E. Jones wrote:
>     Paul, I read your message, but was left unsure of exactly how we
>     could improve the definition over what we have already. If there
>     is something concrete that you can propose that would help lend to
>     clarity of the text, I'm definitely willing to put it in. I would
>     like to move the requirements along and the submission deadline is
>     Monday. Do you have text you would like to add before the
>     deadline? I'm traveling on business and have limited internet
>     access, and limited time, so I probably can't. In any case, ISTM
>     that the problem isn't that we don't have the right words. Rather,
>     we still don't have clear *concepts* that distinguish ! whatshould
>     be covered from what should not. We have some use cases, but lack
>     basic principles that can be applied to any case to determine if
>     it should be a communication session or not. It still seems to be
>     more in the realm of "I know one when I see it." If we had the
>     principles, then it would probably be straightforward to come up
>     with words. I don't yet see a suitable general principle here that
>     fits the use cases and seems to make sense. Thanks, Paul Paul
>     -----Original Message----- From: [email-masked]
>     [mailto:[email-masked]] On Behalf Of Paul Kyzivat Sent:
>     Friday, January 11, 2013 3:34 PM To: [email-masked] Subject: Re:
>     [Insipid] Are we ready to LC on the requirements? (Sorry that this
>     is long. I don't know how to make it short.) Are we ready to LC? I
>     don't think so. Specifically I don't think we yet have an
>     unambiguous definition of what is being identified. This version
>     added some new text: 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 existenc! e 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 Figure 1 - Communication Session through a Middlebox In
>     such cases, the two SIP transactions or dialogs are part of a
>     single communication session. 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. IMO this is a big improvement. But it still
>     isn't as prec! ise as I would like. What I find lacking in the
>     above is: o parsing the above, the properties of a communication
>     session are: - connects *two* UAs - optionally includes one or
>     more intermediary devices - one or more transactions - one
>     out-of-dialog transaction, OR a dialog including the dialog
>     establishing transaction and some transactions within the dialog.
>     - middle boxes may result in chaining dialogs or transactions.
>     Exactly how all these properties "plug together" fuzzy. I'm not at
>     all certain that all readers would reach the same conclusion about
>     which cases meet these criteria and which don't. o I'm also not
>     certain that these criteria match all the cases people expect, and
>     exclude all the cases people think should be excluded. - I think
>     people expect that a conference is *not* a single communications
>     session. But a conference with only two participants would! seem
>     to qualify according to all of the above criteria. So that
>     suggests that another criterion is needed to exclude that case. -
>     A topologically similar case to the conference is a click-to-dial
>     case where a web! server makes outward INVITEs to two UAs and
>     connects them. I think people believe this case *should* be a
>     communications session. - Another case is described in
>     http://www.ietf.org/mail-archive/web/insipid/current/msg00429.html
>     and debated in the replies to that. Arguments are made for
>     different answers to what should get a common session id and what
>     should not. For this case I think we need to decide: . do we
>     mandate exactly how this should be treated? . or do we leave it to
>     the discretion of the B2BUA to decide? Either way we need to
>     decide what the criteria are that lead to the decision. o! IIRC
>     Hadriel suggested (in a meeting?) that where media originates and
>     terminates has something to do with this. That doesn't work all
>     the time (e.g. MESSAGE), but it might help in some cases. I think
>     he used this to just! ify that: - the Conference Bridge
>     Transcoding Model (RFC5369 section 3.2) is a single communications
>     session. - the 3PCC Transcoding Model (RFC5369 section 3.1) is
>     *not* a single communications session. (I'm not convinced - this
>     seems like a distinction without a difference.) Fundamentally we
>     should be able to classify all cases into: - those that *should*
>     be communications sessions, - those that *shouldn't* be
>     communication sessions, - those we don't care about - could be
>     either way. When we are done, we should be able to apply the
>     definition of communication session to any case. When applied to
>     the cases we explicitly care about it should deliver the an! swer
>     we expect. The more weird cases we care about, the more complex
>     and unintuitive the criteria will be. I suspect that the path we
>     are on will lead to complex criteria. (We can have a really crisp
>     de! finition of communications session if we don't care much about
>     which cases qualify.) One idea I considered is to define some new
>     terms that build on normal sip concepts but extend them to allow
>     B2BUA intermediaries where sip allows proxies. E.g. -
>     Transaction++ is either a sip transaction, or a series of sip
>     transactions linked by B2BUA intermediaries. - Dialog++ is either
>     a sip dialog, or a series of sip dialogs linked by B2BUA
>     intermediaries. Then would need to define the behavior of a B2BUA
>     intermediary. It needs to relay transactions from one "side" to
>     the other, preserving certain invariants (TBD). Presumably it can
>     also originate certain transactions, but there must be constraints
>     ! on what it can do. There must also be some rules on how media is
>     handled across one of these intermediaries. If that was done, then
>     a communication session could be defined as a Transaction++ for an
>     out-of-dialog request, or a Dialog++. But that makes the
>     definition of communication session the first priority and the
>     cases that happen to qualify as a communication session a
>     consequence. It probably won't match people's intuitive feelings
>     about what *should* be a communication session. So it might not
>     satisfy people. Thanks, Paul On 1/10/13 6:04 PM, Charles Eckel
>     (eckelcu) wrote: From my point of view, the draft looks good. The
>     changes incorporated in this updated version directly address this
>     open issue. Cheers, Charles -----Original Message----- From:
>     [email-masked] [mailto:[email-masked]] On
>     Behalf Of Gonzalo Salgueiro (gsalguei) Sent: Thursday, January 10,
>     2013 12:39 PM To: Paul E. Jones Cc: [email-masked] Subject: Re:
>     [Insipid] Are we ready to LC on the requirements? Thanks for
>     submitting this, Paul. The biggest open issue in regards to the
>     requirements document was to clearly define what it is we are
>     identifying (i.e., "communication session") within the scope of
>     this document and ensure that clearly defined language is used
>     consistently through! out the document. Prior to any consensus on
>     moving to WGLC, the chairs would appreciate hearing the group's
>     thoughts on where we are on this issue in the current version.
>     Cheers, Gonzalo & Keith On Jan 9, 2013, at 9:23 PM, Paul E. Jones
>     wrote: Folks, Dialog has been extremely light on the requirements
>     document. Do people feel generally OK with it as it is now? Can we
>     move on to the solution document now or are there other changes
>     needed in the requirements document? I just posted the -04 versi!
>     on with changes proposed on the list over the past month or so. Paul
>     ------------------------------------------------------------------------
>     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
>     ------------------------------------------------------------------------
>     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: "Paul E. Jones" <[email-masked]>
Date: Mon, 4 Mar 2013 09:27:44 -0500

Robert,

We'll try to cover this in the meeting with slides and then incorporate in
slides subsequently.  I have an answer for each.  That said, please do allow
me to provide an answer below that we can discuss before then.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Robert Sparks
Sent: Friday, March 01, 2013 3:18 PM
To: Paul E. Jones
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [Insipid] Are we ready to LC on the requirements?

Paul,

That still begs the question of "what language do we need to add or change
to make this clear?" In my mind, I know exactly what an endpoint needs to do
and what an SBC needs to do. But, I'll not say it does not need more charity
for those that do not have it clear in their minds.

But, perhaps being too close to the work, I'm having trouble seeing where it
is vague. Can you suggest text?

This is frustrating, for both of us probably. I've read the latest
requirement document and it doesn't yet clearly
answer the questions I asked in the Atlanta meeting. I feel like I've asked
them at several meetings before.
Can we stop that cycle of repeating the discussion by putting text in the
document that directly answers each of these:

In a scenario where you only have one parallel forking SIP proxy, when an
INVITE forks to two different
UAs and _both_ send 200 OKs, do you have one session or two? (This same
question applies to early dialogs,
with or without early media, which is a _normal_ condition, not an race
condition like multiple 200 OKs).

PEJ: That would be two communication sessions, one between Alice to Bob-1
and one between Alice and Bob-2.  This is precisely why we use the approach
in our proposed solution.  The Session-ID is always comprised of the UUID
values from each "endpoint" (which would include MCUs, PSTN GWs, or 3PCC
session initiators).

If you replace that with a _serial_ forking proxy, where you were in an
early dialog with UA1, that got canceled
and then you ended up in an early dialog, and then a confirmed dialog with
UA2, was that one session (with the
calling UA, UA1, and UA2 involved) or two sessions (one with the calling UA
and UA1, the other with the calling
UA and UA2)?

PEJ: That would be two communication sessions.  Any time there is a
different UA on one end, that represents a distinct communication session.

If you replace that with a B2BUA that behaves similar to a serial forking
proxy in that it only alerts one called thing
at a time, do you end up with one session or with two.

PEJ: This is similar to the case where a fork is cancelled.  Alice is only
in one communication session and the SBC has to pick a UUID to return.
However, the UUID can change if the other device actually answers.  For that
matter, the SBC could even fabricate a temporary value, knowing there is a
50/50 change it will change, anyway.  What's important is the end result:
the "stable call".  Once the call is connected, there are just two devices,
Alice and some Bob.  And, if the Bob changes during call establishment, the
UUID value will change on that end.  That's perfectly fine.

Paul

I don't see how the current document answers those questions. If I've missed
that, please point to it and I'll see how
I can help make them more obvious.

Otherwise, can you please make the answers clear in the document, (not just
in an email response).

Paul

  _____  

From: Paul Kyzivat  <mailto:[email-masked]> <[email-masked]>
Sent: Sun Feb 24 01:43:57 EST 2013
To: "Paul E. Jones"  <mailto:[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: Re: [Insipid] Are we ready to LC on the requirements?

Paul,
 
So what concept is vague?
 
In terms of an H.323 device, I would consider two terminals with users
at each end to be a communication session. I would consider a terminal
and an MCU to have a communication session.
 
The collection of communication sessions on an MCU to which one or more
terrminals are a party is a conference. And I would like to relate all
those sessions by the UUID the MCU uses in each of those sessions. That
value could even be the Conference ID in H.323.
 
There are gateway devices that connect to the PSTN that I would count as
equal to a terminal. But, there are gateway devices that bridge IP
networks (SBCs) that shoul!
 d just
pass the UUIDs through. The difference
between the two really is whether it bridges an IPMC device to another
or to something else.
 
There are call flows like the one you highlighted in the threads where
voice comes from one terminal and video from another. That's an MCU,
really. The session ID exists between Alice and MCU (or PBX). The other
devices Bob uses might share the UUID of the MCU/PBX, but those are
distinct communication sessions like the typical MCU case. Yeah, such
topologies do make it hard to do debugging and the number of UUIDs makes
it a pain, too, but at least there is consistency in the assignments.
So, it is doable.
 
So, how can we make progress here?

 
 
 Thanks,
 Paul K

Paul

  _____  

*From:* Paul Kyzivat  <mailto:[email-masked]> <[email-masked]>
*Sent:* Sat F!
 eb 23
19:58:41 EST 2013
*To:* "Paul E. Jones"  <mailto:[email-masked]>
<[email-masked]>
*Cc:* [email-masked]
*Subject:* Re: [Insipid] Are we ready to LC on the requirements?
 
On 2/21/13 9:51 PM, Paul E. Jones wrote:
 
Paul,
 
I read your message, but was left unsure of exactly how we could
improve the
definition over what we have already.
 
If there is something concrete that you can propose that would help
lend to
clarity of the text, I'm definitely willing to put it in. I would
like to
move the requirements along and the submission deadline is Monday.
Do you
have text you would like to add before the deadline?

I'm traveling on business and have limited internet access, and limited
time, so I probably can't.
 
In any case, ISTM that the problem isn't that we don't have the right
words. Rather, we still don't have clear *concepts* that distinguish
!
whatshould be covered from what should not. We have some use cases, but
lack basic principles that can be applied to any case to determine if it
should be a communication session or not. It still seems to be more in
the realm of "I know one when I see it."
 
If we had the principles, then it would probably be straightforward to
come up with words.
 
I don't yet see a suitable general principle here that fits the use
cases and seems to make sense.
 
Thanks,
Paul
 
Paul
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Friday, January 11, 2013 3:34 PM
To: [email-masked]
Subject: Re: [Insipid] Are we ready to LC on the requirements?
 
(Sorry that this is long. I don't know how to make it short.)
 
Are we ready to LC? I don't think so. Specifically I don't think
we yet
have an
unambiguous definition of what is being identified.
 
This version added some new text:
 
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
existenc! e 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
 
Figure 1 - Communication Session through a Middlebox
 
In such cases, the two SIP transactions or dialogs are part of a
single communication session.
 
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.
 
IMO this is a big improvement. But it still isn't as prec! ise
as I would
like. What I find lacking in the above is:
 
o parsing the above, the properties of a communication session are:
- connects *two* UAs
- optionally includes one or more intermediary devices
- one or more
transactions
- one out-of-dialog transaction,
OR a dialog including the dialog establishing transaction
and some transactions within the dialog.
- middle boxes may result in chaining dialogs or transactions.
 
Exactly how all these properties "plug together" fuzzy.
I'm not at all certain that all readers would reach
the same conclusion about which cases meet these criteria
and which don't.
 
o I'm also not certain that these criteria match all the cases
people expect, and exclude all the cases people think should
be excluded.
 
- I think people expect that a conference is *not* a single
communications session. But a conference with only two
participants would! seem to qualify according to all of the
above criteria. So that suggests that another criterion is
needed to exclude that case.
 
- A topologically similar case to the conference is a
click-to-dial case where a web!
  server
makes outward INVITEs
to two UAs and connects them. I think people believe this
case *should* be a communications session.
 
- Another case is described in
http://www.ietf.org/mail-archive/web/insipid/current/msg00429.html
and debated in the replies to that. Arguments are made for
different answers to what should get a common session id and what
should not. For this case I think we need to decide:
. do we mandate exactly how this should be treated?
. or do we leave it to the discretion of the B2BUA to decide?
 
Either way we need to decide what the criteria are that lead
to the decision.
 
o! IIRC Hadriel suggested (in a meeting?) that where media
originates and terminates has something to do with this.
That doesn't work all the time (e.g. MESSAGE), but it might help
in some cases. I think he used this to just!
 ify
that:
 
- the Conference Bridge Transcoding Model (RFC5369 section 3.2)
is a single communications session.
 
- the 3PCC Transcoding Model (RFC5369 section 3.1) is *not*
a single communications session.
 
(I'm not convinced - this seems like a distinction without
a difference.)
 
Fundamentally we should be able to classify all cases into:
- those that *should* be communications sessions,
- those that *shouldn't* be communication sessions,
- those we don't care about - could be either way.
 
When we are done, we should be able to apply the definition of
communication session to any case. When applied to the cases we
explicitly care about it should deliver the an! swer we expect.
 
The more weird cases we care about, the more complex and
unintuitive the
criteria will be. I suspect that the path we are on will lead to
complex
criteria. (We can have a really crisp de!
 finition
of communications
session if we don't care much about which cases qualify.)
 
One idea I considered is to define some new terms that build on
normal
sip concepts but extend them to allow B2BUA intermediaries where sip
allows proxies. E.g.
- Transaction++ is either a sip transaction, or a series of sip
transactions linked by B2BUA intermediaries.
 
- Dialog++ is either a sip dialog, or a series of sip dialogs
linked by B2BUA intermediaries.
 
Then would need to define the behavior of a B2BUA intermediary.
It needs
to relay transactions from one "side" to the other, preserving
certain
invariants (TBD). Presumably it can also originate certain
transactions,
but there must be constraints ! on what it can do. There must
also be some
rules on how media is handled across one of these intermediaries.
 
If that was done, then a communication session could be defined as a
Transaction++ for an out-of-dialog request, or a Dialog++.
 
But that makes the definition of communication session the first
priority and the cases that happen to qualify as a communication
session
a consequence. It probably won't match people's intuitive
feelings about
what *should* be a communication session. So it might not
satisfy people.
 
Thanks,
Paul

On 1/10/13 6:04 PM, Charles Eckel (eckelcu) wrote:
 
>From my point of view, the draft looks good. The
changes incorporated
 
in this updated version directly address this open issue.
 
Cheers,
Charles
 
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On
Behalf Of Gonzalo Salgueiro (gsalguei)
Sent: Thursday, January 10, 2013 12:39 PM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: [Insipid] Are we ready to LC on the
requirements?
 
Thanks for submitting this, Paul. The biggest open issue
in regards
to the requirements document was to clearly define what
it is we are
identifying (i.e., "communication session") within the
scope of this
document and ensure that clearly defined language is used
consistently through! out the document. Prior to any
consensus on
moving to WGLC, the chairs would appreciate hearing the
group's
thoughts on where we are on this issue in the current
version.
 
Cheers,
 
Gonzalo & Keith

On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote:
 
Folks,
 
Dialog has been extremely light on the requirements
document. Do
 
people feel generally OK with it as it is now? Can we
move on to the
solution document now or are there other changes needed
in the
requirements document?
 
I just posted the -04 versi!
 on with
changes proposed
on the list over
the
 
past month or so.
 
Paul

  _____  

insipid mailing list
[email-masked]

  _____  

insipid mailing list
[email-masked]

  _____  

insipid mailing list
[email-masked]

  _____  

insipid mailing list
[email-masked]

  _____  

insipid mailing list
[email-masked]

---

From: Robert Sparks <[email-masked]>
Date: Mon, 04 Mar 2013 09:10:31 -0600

On 3/4/13 8:27 AM, Paul E. Jones wrote:
>
> Robert,
>
> We'll try to cover this in the meeting with slides and then 
> incorporate in slides subsequently.  I have an answer for each.  That 
> said, please do allow me to provide an answer below that we can 
> discuss before then.
>
> Paul
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Robert Sparks
> *Sent:* Friday, March 01, 2013 3:18 PM
> *To:* Paul E. Jones
> *Cc:* [email-masked]; Paul Kyzivat
>     That still begs the question of "what language do we need to add
>     or change to make this clear?" In my mind, I know exactly what an
>     endpoint needs to do and what an SBC needs to do. But, I'll not
>     say it does not need more charity for those that do not have it
>     clear in their minds.
>
>     But, perhaps being too close to the work, I'm having trouble
>     seeing where it is vague. Can you suggest text?
>
> UAs and _both_ send 200 OKs, do you have one session or two? (This 
> same question applies to early dialogs,
> with or without early media, which is a _normal_ condition, not an 
> race condition like multiple 200 OKs).
>
> PEJ: That would be two communication sessions, one between Alice to 
> Bob-1 and one between Alice and Bob-2.  This is precisely why we use 
> the approach in our proposed solution.  The Session-ID is always 
> comprised of the UUID values from each "endpoint" (which would include 
> MCUs, PSTN GWs, or 3PCC session initiators).
>
>
> If you replace that with a _serial_ forking proxy, where you were in 
> an early dialog with UA1, that got canceled
> calling UA, UA1, and UA2 involved) or two sessions (one with the 
> calling UA and UA1, the other with the calling
> UA and UA2)?
>
> PEJ: This is similar to the case where a fork is cancelled. Alice is 
> only in one communication session and the SBC has to pick a UUID to 
> return.  However, the UUID can change if the other device actually 
> answers.  For that matter, the SBC could even fabricate a temporary 
> value, knowing there is a 50/50 change it will change, anyway.  What's 
> important is the end result: the "stable call".  Once the call is 
> connected, there are just two devices, Alice and some Bob.  And, if 
> the Bob changes during call establishment, the UUID value will change 
> on that end. That's perfectly fine.
>
I had to read this several times to make sure, but I think the end 
result is that you said "two" (or perhaps even three) here, but if you 
were looking at whole set of messages between the three UAs involved, 
you would never try to identify them all with a single session 
identifier. Did I hear you correctly?

> *From:*Paul Kyzivat <[email-masked]> <mailto:[email-masked]>
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
>     *From:* Paul Kyzivat<[email-masked]>  <mailto:[email-masked]>
>
>     *Sent:* Sat F!
>
>       eb 23
>
>     19:58:41 EST 2013
>
>     *To:* "Paul E. Jones"<[email-masked]>  <mailto:[email-masked]>
>
>     *Cc:[email-masked]  <mailto:[email-masked]>
>
>     From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On
>
>     Behalf Of Paul Kyzivat
>
>     To:[email-masked]  <mailto:[email-masked]>
>
>     From:[email-masked]  <mailto:[email-masked]>
>
>     Cc:[email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>
> [email-masked]  <mailto:[email-masked]>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 4 Mar 2013 10:43:58 -0500

Robert,

Comments down below:

From: Robert Sparks [mailto:[email-masked]] 
Sent: Monday, March 04, 2013 10:11 AM
To: Paul E. Jones
Cc: [email-masked]; 'Paul Kyzivat'
Subject: Re: [Insipid] Are we ready to LC on the requirements?

Robert,

PEJ: meant to say "document" above.

Paul

Paul,

I had to read this several times to make sure, but I think the end result is
that you said "two" (or perhaps even three) here, but if you were looking at
whole set of messages between the three UAs involved, you would never try to
identify them all with a single session identifier. Did I hear you
correctly?

PEJ: Alice sends an INVITE and gets back a single 180, even if the B2BUA
gets 10 180s, right?  In that case, there are 10 Bobs ringing and there
would be 10 communication sessions {Alice, Bob-1}, {Alice, Bob-2}, ..
However, only the SBC sees those.  That's because the SBC is not forwarding
all messages to Alice.  The SBC is going to forward something to Alice.
Would this be Bob-1 or some UUID fabricated by the SBC?  Does not really
matter, since the remote end is allowed to change.  So, the SBC could send a
UUID such that Alice has {Alice, SBC}, but then when Bob-5 sends a 200,
Alice updates her Session-ID to be { Alice, Bob-5 }.  Because session
establishment works like this, we need something that is flexible enough to
accommodate.  That's the reason we propose to use two UUIID values.  Each
UUID identifies a particular physical or logical endpoint in a session.  The
set of two UUIDs define the communication session comprised of those two
endpoints.

Paul

Paul

Paul

  _____  

Paul,

 

 

 
 
 Thanks,
 Paul K

Paul

  _____  

 
Paul,

 

 
Thanks,
Paul
 
Paul
 
-----Original Message-----

 

A Middlebox B
SIP trans1

 

 

 

 

 

 

 

 
Thanks,
Paul

changes incorporated

Cheers,
Charles
 
-----Original Message-----

Cheers,
 
Gonzalo & Keith

 
Folks,

 
 
past month or so.
 
Paul

  _____  

insipid mailing list
[email-masked]

  _____  

insipid mailing list
[email-masked]

  _____  

insipid mailing list
[email-masked]

  _____  

insipid mailing list
[email-masked]

  _____  

insipid mailing list
[email-masked]

---

From: Robert Sparks <[email-masked]>
Date: Mon, 04 Mar 2013 10:07:21 -0600

Trimming a bit.

On 3/4/13 9:43 AM, Paul E. Jones wrote:
> *From:* Robert Sparks [mailto:[email-masked]]
>
>     PEJ: This is similar to the case where a fork is cancelled.  Alice
>     is only in one communication session and the SBC has to pick a
>     UUID to return.  However, the UUID can change if the other device
>     actually answers.  For that matter, the SBC could even fabricate a
>     temporary value, knowing there is a 50/50 change it will change,
>     anyway.  What's important is the end result: the "stable call". 
>     Once the call is connected, there are just two devices, Alice and
>     some Bob.  And, if the Bob changes during call establishment, the
> PEJ: Alice sends an INVITE and gets back a single 180, even if the 
> B2BUA gets 10 180s, right?  In that case, there are 10 Bobs ringing 
> and there would be 10 communication sessions {Alice, Bob-1}, {Alice, 
> Bob-2}, ....  However, only the SBC sees those.  That's because the 
> SBC is not forwarding all messages to Alice.  The SBC is going to 
> forward /something/ to Alice.  Would this be Bob-1 or some UUID 
> fabricated by the SBC?  Does not really matter, since the remote end 
> is allowed to change.  So, the SBC could send a UUID such that Alice 
> has {Alice, SBC}, but then when Bob-5 sends a 200, Alice updates her 
> Session-ID to be { Alice, Bob-5 }. Because session establishment works 
> like this, we need something that is flexible enough to accommodate.  
> That's the reason we propose to use two UUIID values.  Each UUID 
> identifies a particular physical or logical endpoint in a session.  
> The set of two UUIDs define the communication session comprised of 
> those two endpoints.
>
>
You probably aren't doing this on purpose, but it feels like you are 
trying to avoid answering my direct questions.

I would be a lot more comfortable that we're not talking past each other 
if you had said clearly "yes" or "no" above
(and then launched into an explanation if you needed to). I think you 
said "yes", and then explained more about
why "perhaps even three" might be the case. Would you confirm that?

And specifically, you agree that "If you were looking at the whole set 
of messages between the three UAs involved, you would never try to 
identify them all with a single session identifier."?

If you aren't comfortable just saying yes to both of those things, we 
need to discuss more about why. If you are, then we can move on to the 
next step of working that into a description of what this identifier is 
identifying.

RjS

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 4 Mar 2013 11:38:06 -0500

Robert,

Comments below:

From: Robert Sparks [mailto:[email-masked]] 
Sent: Monday, March 04, 2013 11:07 AM
To: Paul E. Jones
Cc: [email-masked]; 'Paul Kyzivat'
Subject: Re: [Insipid] Are we ready to LC on the requirements?

Trimming a bit.

You probably aren't doing this on purpose, but it feels like you are trying
to avoid answering my direct questions.

I would be a lot more comfortable that we're not talking past each other if
you had said clearly "yes" or "no" above 
(and then launched into an explanation if you needed to). I think you said
"yes", and then explained more about 
why "perhaps even three" might be the case. Would you confirm that?

PEJ: Yes :-) I apologize for adding more text, but I got the impression you
were still unsure and I'm willing to explain all day.

And specifically, you agree that "If you were looking at the whole set of
messages between the three UAs involved, you would never try to identify
them all with a single session identifier."?

PEJ: Correct.  (Optional-to-read elaboration: Alice would use the same UUID
between her and the two Bobs.  However, each Bob would use a distinct UUID
and therefore the Session-IDs would be different between Alice and Bob-1 as
compared to Alice and Bob-2.)

Paul

If you aren't comfortable just saying yes to both of those things, we need
to discuss more about why. If you are, then we can move on to the next step
of working that into a description of what this identifier is identifying.

RjS