Subject: [dispatch] Session-Id: Problem 3: A session is limited to two endpoints

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 9 Nov 2011 13:54:47 -0500

part 1:

> From: Paul E. Jones [[email-masked]]
> 
> A Session-ID is intended to be unique between any two communicating
> endpoints.  So, if Alice makes a call and connects to Bob, there would
> be a Session-ID that is end-to-end unique between Alice and Bob.  If
> an intermediary re-routes the call such that Alice is now in
> communication with Sue, then there would be a new unique Session-ID
> between Alice and Sue.  Likewise, if Alice calls Bob, but there is a
> forking proxy that causes the call to be forked to 15 “Bobs”, then
> there would be 15 Session-IDs, one for each pair of { Alice, Bob(i) }.
> The Session-ID is unique between any two communicating endpoints.

So to summarize, if a single INVITE forks to two destinations, the
resulting dialogs are two sessions, and need separate Session-Ids.
The interesting point is that the dialogs have the *same* Call-Id.

Logically, the mapping from Call-Id to Session-Id is not many-to-one,
although the mapping from dialog identifiers (Call-Id, caller-tag,
callee-tag) to Session-Id is still many-to-one.

Functionally, a Session-Id cannot be assigned before the INVITE
reaches the endpoint; the Session-Id first appears in the 2xx response
from the destination endpoint.

part 2:

Another case which bedevils the definitions:

1. Alice calls Bob through a B2BUA functioning as an SBC.
There are two SIP dialogs, Alice-SBC and SBC-Bob.
2. Bob transfers the call to Carol by sending toward Alice a REFER with
Refer-To: sip:carol.
3. The SBC "shortstops" the REFER by obeying it itself, so it creates a
dialog to Carol, SBC-Carol.  Through passing SDP through or altering
its RTP relaying, the dialog Alice-SBC is used for the communication
with Carol.

In the initial phase, the dialogs Alice-SBC and SBC-Bob are part of
one session, and share a Session-Id.  In the second phase, the dialogs
Alice-SBC and SBC-Carol are part of a *different* session, despite
that the dialog Alice-SBC has not changed.

In this situation, even the mapping from dialog identifiers to
Session-Ids is not many-to-one, and the Session-Id of a dialog changes
over time.

How are we to signal to Alice that the Session-Id of her dialog has
changed?

part 3:

Now to combine these to make a really nasty example!

1. Alice calls Bob.  The Alice-Bob dialog is assigned a Session-Id by
Bob.

2. Alice wants to do an attended transfer of the call to Carol.  She
puts the dialog with Bob on hold, and initiates a call to sip:carol.
(BTW, is the hold music from the MOH server to Bob yet another
session?)

3. The call to sip:carol forks to two UAs.  Carol answers the call on
one, and her UA assigns a Session-Id to the Alice-Carol dialog.

4. Dave answers the call on the other UA, and his UA assigns a
Session-Id to the Alice-Dave dialog.

5. Alice ends the Alice-Dave dialog.

6. Alice executes the transfer, sending an INVITE-with-Replaces to
Carol to make her UA establish a dialog with Bob.  The new Carol-Bob
dialog is assigned a further Session-Id.

(This can be made more complicated by inserting SBCs into the flow
in various places.)

I believe that this example excludes all proposed definitions of
"session":  For every definition of "session", there is no
implementation that can assign Session-Ids correctly in this example.

Dale

"In cooperation with an intelligent joiner I would undertake to defeat
any definition of chair or chairishness that you gave me."
-- H. G. Wells, "A Modern Utopia"

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 11 Nov 2011 12:03:16 -0500

Dale,

I appreciate your intervention... you're helping to bring clarity to the

> The interesting point is that the dialogs have the *same* Call-Id.

Two different Session-IDs (since there are two different remote devices),
but the same Call-ID.
 
> Functionally, a Session-Id cannot be assigned before the INVITE reaches
> the endpoint; the Session-Id first appears in the 2xx response from the
> destination endpoint.

It might arrive even before a 2xx, such as via a 180.  Following our
proposal, the called devices would each return a Session-UUID.  The
concatenation of Alice's UUID and the UUID received from each called device
would result in the creation of a set of Session IDs.  Of course, only one
would be long-lived, but they will all exist in parallel for a short period
of time.
 
> dialog to Carol, SBC-Carol.  Through passing SDP through or altering its
> RTP relaying, the dialog Alice-SBC is used for the communication with
> Carol.
> 
> In the initial phase, the dialogs Alice-SBC and SBC-Bob are part of one
> session, and share a Session-Id.  In the second phase, the dialogs
> Alice-SBC and SBC-Carol are part of a *different* session, despite that
> the dialog Alice-SBC has not changed.

Correct.  However, I would want Alice to be aware that the Session-ID has
changed.  So via some signaling message, I would want the SBC to inform
Alice of the new Session-UUID that is associated with Carol.
 
> In this situation, even the mapping from dialog identifiers to Session-
> Ids is not many-to-one, and the Session-Id of a dialog changes over
> time.

Correct.
 
> How are we to signal to Alice that the Session-Id of her dialog has

One solution is to just send a new INVITE from the SBC to Alice containing
the revised Session-UUID.  This would not require changes in SDP if the
codecs do not change and the SBC is proxying media.  However, that might not
be the ideal solution.  I'd accept any proposal (e.g., INFO or other).
 
> 1. Alice calls Bob.  The Alice-Bob dialog is assigned a Session-Id by

To be clear, we are proposing that Alice assign half of the Session-ID and
Bob assign the other half.  Each half would be a UUID.

> (BTW, is the hold music from the MOH server to Bob yet another

The MOH going to Bob may be a new session.  If Bob is REFERred to a parking
lot, then yes.  If Alice somehow interacts with a media server and
re-negotiates flows so that music goes from the server to Bob, but Alice
remains the "endpoint" in the call, then the Session-ID does not change.
 
> one, and her UA assigns a Session-Id to the Alice-Carol dialog.

Carol would assign one UUID, but you're nonetheless correct that we will
have an new and entirely different Session-ID between Alice-Carol that is
distinct from Alice-Bob.

> 4. Dave answers the call on the other UA, and his UA assigns a Session-
> Id to the Alice-Dave dialog.
> 
> 6. Alice executes the transfer, sending an INVITE-with-Replaces to Carol
> to make her UA establish a dialog with Bob.  The new Carol-Bob dialog is
> assigned a further Session-Id.

In this scenario, what I would like to see happen is that the Carol-Bob
session would use the UUID Carol created and the UUID Bob created when Carol
was talking with Alice and when Bob was talking with Alice.  We could create
an entirely new Session-ID, but re-using the UUIDs allows us to trace the
progress of a call, since these values are globally unique and would allow
us to better trace the progression of a call.  In all cases, the
concatenation of two UUIDs results in a unique Session-ID that is not
repeated between any other two devices.
 
> (This can be made more complicated by inserting SBCs into the flow in
> various places.)
> 

We may need a revised definition :-)

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Nov 2011 04:12:46 +0000

>> RTP relaying, the dialog Alice-SBC is used for the communication with

Actually, I think the SBC should create a session-id of "Alice-Carol", using the same "Alice" portion as the original "Alice-Bob" dialog - since that's what would have happened had the REFER gone all the way back to Alice.  But the difference probably doesn't matter much for this discussion.

> Alice of the new Session-UUID that is associated with Carol.

Why does Alice need to be made aware of this?  What's Alice going to use the session-id for in the future that requires her to know it?

I ask because the reasons SBC process REFERS instead of passing them back are some of the same reasons PBX's do so: (1) because many UAs can't process REFER or do so correctly, (2) because the transfer even is a local event and the admin doesn't want Alice's UA to know/care about it occurring, and (3) there's additional policy/logic that the SBC/PBX applies to transferred calls.  Expecting the SBC to send re-INVITEs/INFO to Alice to make her aware of the transfer goes against (1) and (2), so I doubt it will happen.

Once the SBC processes the REFER itself, it's now switched into being an "endpoint" role (to use the terminology you were using before).

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 12 Nov 2011 23:56:08 -0500

Hadriel,

> >> 3. The SBC "shortstops" the REFER by obeying it itself, so it creates
> >> a dialog to Carol, SBC-Carol.  Through passing SDP through or
> >> altering its RTP relaying, the dialog Alice-SBC is used for the
> >> communication with Carol.
> 
> Actually, I think the SBC should create a session-id of "Alice-Carol",
> using the same "Alice" portion as the original "Alice-Bob" dialog -
> since that's what would have happened had the REFER gone all the way
> back to Alice.  But the difference probably doesn't matter much for this
> discussion.

Yes, that's what should happen.  The SBC would forward to Carol Alice's
Session-UUID.  Likewise, it would forward to Alice Carol's Session-UUID (via
INVITE or whatever).
 
> >> one session, and share a Session-Id.  In the second phase, the
> >> dialogs Alice-SBC and SBC-Carol are part of a *different* session,
> >> despite that the dialog Alice-SBC has not changed.
> >
> > Correct.  However, I would want Alice to be aware that the Session-ID
> > has changed.  So via some signaling message, I would want the SBC to
> > inform Alice of the new Session-UUID that is associated with Carol.
> 
> Why does Alice need to be made aware of this?  What's Alice going to use
> the session-id for in the future that requires her to know it?

There are lots of things:
1) Logging
2) Billing
3) Signaling / media correlation
4) troubleshooting
5) call tracing

We wanted a Session-ID that is end-to-end, so Alice needs to know if an
identifier changes so she can take appropriate action.  Perhaps she does not
care, but there are definitely things I'd like to do knowing the current
end-to-end identifier for a call.

If we did not change this value, then we might actually have multiple
devices reporting that they are the same Session-ID when, in fact, they're
not.  Consider Alice calling Bob and then both devices being redirected
elsewhere.  If they were not made aware of a change in the opposite
endpoint, they would both log the same Session-ID even after the they were
no longer communicating with each other and communicating with some other
endpoint.
 
> I ask because the reasons SBC process REFERS instead of passing them
> back are some of the same reasons PBX's do so: (1) because many UAs
> can't process REFER or do so correctly, (2) because the transfer even is
> a local event and the admin doesn't want Alice's UA to know/care about
> it occurring, and (3) there's additional policy/logic that the SBC/PBX
> applies to transferred calls.  Expecting the SBC to send re-INVITEs/INFO
> to Alice to make her aware of the transfer goes against (1) and (2), so
> I doubt it will happen.

If we sent an INFO message to update Alice's understanding of the remote
entities Session-UUID, she'll either do something with it or ignore it.  If
she is making active use of the Session-ID, she should take note of the
change.  If she is not, then there's no harm done.  She would just ignore
the INFO message.

> Once the SBC processes the REFER itself, it's now switched into being an
> "endpoint" role (to use the terminology you were using before).

But it's not: it's still an intermediary.  If it every switched into an
endpoint role (e.g., such as becoming a conference focus), it should
manufacture its own Session-UUID to send to other endpoints in the
conference.  In the scenarios you've described, it is still an intermediary,
though.

Paul

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 13 Nov 2011 14:41:58 +0100

What would happen in case of "SPLICES".
Assume you have a video/audio connection between two endpoints.
Is it correct, that both audio and video communication would share the
same Session-ID?
If one endpoint change the entity for video communication only, would a
new Session-ID for this purpose?

Christian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Worley, Dale R (Dale)
Sent: Wednesday, November 09, 2011 7:55 PM
To: [email-masked]
Subject: [dispatch] Session-Id: Problem 3: A session is limited to
twoendpoints

part 1:

> forking proxy that causes the call to be forked to 15 "Bobs", then

part 2:

part 3:

Dale

"In cooperation with an intelligent joiner I would undertake to defeat
any definition of chair or chairishness that you gave me."
-- H. G. Wells, "A Modern Utopia"
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 13 Nov 2011 10:42:27 -0500

> new Session-ID for this purpose?

It will be interesting to get the author's opinion on this. :-)

IMO, *if* there is one device anchoring the a/v, and delegating the 
video to another sip device:

                 (sip)
	A -------------------- B
           ====================
         |      (audio)         =
   (sip) |                      =
         C ======================
                (video)

then I think you want one session id for AB and another for AC,
with B never knowing that C is involved. So A is acting as an endpoint, 
at least for the A-B session.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 13 Nov 2011 12:14:23 -0500

Christian,

That should not change the Session ID.  For all intents and purposes, the
video devices are a logical extension of the user agent that either placed
or received the call.  So, switching a new video device should make no
difference.  It's similar to swapping out monitors connected to your PC.

That said, if the separate video or audio devices are to utilize the
Session-ID (e.g., inserting it into an RSVP PATH message), then those
devices need to be told what Session-ID to use.  In what we proposed in our
draft, each entity provides half of the Session-ID via the "Session-UUID"
header.  How is it that communication is to be established with these other
devices?  Will it be via a SIP INVITE or some other mechanism?  We might
need a means of assigning an ID in this case vs. proposing only 1/2 of the
value.

Paul

> Behalf Of Schmidt, Christian 1. (NSN - DE/Munich)
> Sent: Sunday, November 13, 2011 8:42 AM
> To: ext Worley, Dale R (Dale); [email-masked]
> Subject: Re: [dispatch] Session-Id: Problem 3: A session is limited to
> twoendpoints
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 14 Nov 2011 03:21:50 +0000

> 3) Signaling / media correlation

I don't know what "signaling/media correlation" really means or implies from a SIP protocol perspective interacting with Session-ID.

I do know what billing means, and I don't think we should touch that topic for Session-ID - both because it's a rat's nest of requirements that are unique for different markets/countries, but also because I'm not sure the IETF has the appropriate knowledge experts for that topic area.

I would categorize "logging", "troubleshooting", and "call-tracing" as all the same topic, and you *do* get them without having to update Alice's Session-ID; the UUID she created for the original call to Bob is the same one used in the new dialog to Carol.  Each UUID of the two used in a Session-ID is independently usable for tracking across the networks - that's one of the reasons I suggested that if we go with this approach we make them separate token fields, to make that more obvious/clear.

> identifier changes so she can take appropriate action.  

So what is this "action"?  What change to SIP processing rules or application logic are we trying to enable with a Session-ID? (I don't count "logging/troubleshooting" as an actionable processing change)

> no longer communicating with each other and communicating with some other

Yes, that was raised as an issue in the original session-id concept as well.  Luckily it didn't matter because session-id was only being used for troubleshooting/logging.  That's why I'm trying to figure out what else this new WG plans to actually do with Session-ID at a SIP layer, that would break SIP if things didn't go as planned/expected.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 13 Nov 2011 23:09:25 -0500

Hadriel,

> >> Why does Alice need to be made aware of this?  What's Alice going to
> >> use the session-id for in the future that requires her to know it?
> >
> I don't know what "signaling/media correlation" really means or implies
> from a SIP protocol perspective interacting with Session-ID.

I would like to be able to use this in other protocols like RSVP.  The
network would then be able to see that a given set of flows are related.
 
> I do know what billing means, and I don't think we should touch that
> topic for Session-ID - both because it's a rat's nest of requirements
> that are unique for different markets/countries, but also because I'm
> not sure the IETF has the appropriate knowledge experts for that topic
> area.

Yeah, I'm not suggesting we go solve billing issues, but a Session-ID
becomes another tool.
 
> I would categorize "logging", "troubleshooting", and "call-tracing" as
> all the same topic, and you *do* get them without having to update
> Alice's Session-ID; the UUID she created for the original call to Bob is
> the same one used in the new dialog to Carol.  Each UUID of the two used
> in a Session-ID is independently usable for tracking across the networks
> - that's one of the reasons I suggested that if we go with this approach
> we make them separate token fields, to make that more obvious/clear.

These are certainly related, but we have to be careful.  You're right that
*if* we go with the approach we propose, the value Alice produced would be
useful by itself -- and that was intended.  However, if I had a management
system that was trying to identify a given call at a given point in time, it
would be useful that I could query a set of intermediary devices and
determine the signaling path, for example.  If we do not update Alice, then
it is entirely possible that we lose that end-to-end concept.  We might have
this series of connections
Alice -> SBC1 -> SBC2 -> SBC3 -> SBC4 -> Carol

After a few service interactions, perhaps SBC3 believes that the Session ID
is {X|Y} when Alice thinks it is {A|B} and Carol thinks it is {C|D}.

Suppose Alice has a button on her phone used to report video quality issues.
Pressing the button might also result in Alice sending the Session ID via
RTCP packets.  Network monitoring devices looking at those packets would
have a hard time identifying the SBC through which the media is flowing if
it cannot query them to determine if it knows about {A|B}.

Anyway, there are many things we can do if the entire path has a common view
of what the Session-ID is.  It does not matter that it changes, so long as
all devices have a common view at any given point in time during the stable
call.
 
> > We wanted a Session-ID that is end-to-end, so Alice needs to know if
> > an identifier changes so she can take appropriate action.
> 
> So what is this "action"?  What change to SIP processing rules or
> application logic are we trying to enable with a Session-ID? (I don't
> count "logging/troubleshooting" as an actionable processing change)

Start logging the right value, sending the right value in RTCP. Perhaps send
a new PATH message with the new value, etc.  The actions are outside the
scope of SIP, but we want to be able to use this value.
 
> > devices reporting that they are the same Session-ID when, in fact,
> > they're not.  Consider Alice calling Bob and then both devices being
> > redirected elsewhere.  If they were not made aware of a change in the
> > opposite endpoint, they would both log the same Session-ID even after
> > the they were no longer communicating with each other and
> > communicating with some other endpoint.
> 
> Yes, that was raised as an issue in the original session-id concept as
> well.  Luckily it didn't matter because session-id was only being used
> for troubleshooting/logging.  That's why I'm trying to figure out what
> else this new WG plans to actually do with Session-ID at a SIP layer,
> that would break SIP if things didn't go as planned/expected.

I do not propose that the WG do anything with the Session-ID.  I only want
us to define one where all devices have a common understanding of what the
value is.  Once we do that, then we can actually rely on it for something
else meaningful.  But, that will be another WG and another charter ;-)

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Nov 2011 00:38:47 -0500

I see you mention using the session id in RSVP and RTCP.
Can you say more about what you have in mind?

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 14 Nov 2011 09:01:17 -0500

Paul,

This is for media flow and signaling correlation.  There are a number of
reasons why this might be useful, but I don't have a proposal for this, yet.
Assuming the work progresses, I will submit proposals for using it in RTCP,
RTP, or other places that might make sense.

Paul

> Behalf Of Paul Kyzivat
> Sent: Monday, November 14, 2011 12:39 AM
> To: [email-masked]
> two endpoints
> >>>> Why does Alice need to be made aware of this?  What's Alice going
> >>>> to use the session-id for in the future that requires her to know
> it?
> >>>
> >> I don't know what "signaling/media correlation" really means or
> >> implies from a SIP protocol perspective interacting with Session-ID.
> >
> >> not sure the IETF has the appropriate knowledge experts for that
> >> topic area.
> >
> >> I would categorize "logging", "troubleshooting", and "call-tracing"
> >> as all the same topic, and you *do* get them without having to update
> >> Alice's Session-ID; the UUID she created for the original call to Bob
> >> is the same one used in the new dialog to Carol.  Each UUID of the
> >> two used in a Session-ID is independently usable for tracking across
> >> the networks
> >> - that's one of the reasons I suggested that if we go with this
> >> approach we make them separate token fields, to make that more
> obvious/clear.
> >
> > *if* we go with the approach we propose, the value Alice produced
> > would be useful by itself -- and that was intended.  However, if I had
> > a management system that was trying to identify a given call at a
> > given point in time, it would be useful that I could query a set of
> > intermediary devices and determine the signaling path, for example.
> > If we do not update Alice, then it is entirely possible that we lose
> > that end-to-end concept.  We might have this series of connections
> > After a few service interactions, perhaps SBC3 believes that the
> > Session ID is {X|Y} when Alice thinks it is {A|B} and Carol thinks it
> is {C|D}.
> >
> > Pressing the button might also result in Alice sending the Session ID
> > via RTCP packets.  Network monitoring devices looking at those packets
> > would have a hard time identifying the SBC through which the media is
> > flowing if it cannot query them to determine if it knows about {A|B}.
> >
> > Anyway, there are many things we can do if the entire path has a
> > common view of what the Session-ID is.  It does not matter that it
> > changes, so long as all devices have a common view at any given point
> > in time during the stable call.
> >
> > Start logging the right value, sending the right value in RTCP.
> > Perhaps send a new PATH message with the new value, etc.  The actions
> > are outside the scope of SIP, but we want to be able to use this
> value.
> >
> >>> If we did not change this value, then we might actually have
> >>> multiple devices reporting that they are the same Session-ID when,
> >>> in fact, they're not.  Consider Alice calling Bob and then both
> >>> devices being redirected elsewhere.  If they were not made aware of
> >>> a change in the opposite endpoint, they would both log the same
> >>> Session-ID even after the they were no longer communicating with
> >>> each other and communicating with some other endpoint.
> >>
> >> Yes, that was raised as an issue in the original session-id concept
> >> as well.  Luckily it didn't matter because session-id was only being
> >> used for troubleshooting/logging.  That's why I'm trying to figure
> >> out what else this new WG plans to actually do with Session-ID at a
> >> SIP layer, that would break SIP if things didn't go as
> planned/expected.
> >
> > I do not propose that the WG do anything with the Session-ID.  I only
> > want us to define one where all devices have a common understanding of
> > what the value is.  Once we do that, then we can actually rely on it
> > for something else meaningful.  But, that will be another WG and
> > another charter ;-)
> >
> > Paul
> >
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Nov 2011 16:29:44 +0000

Hi Paul,
this email's getting long so I'm splitting into two separate responses for different topics.
Comments inline...

> network would then be able to see that a given set of flows are related.

You mean you're going to put the Session-ID value into RSVP path/resv messages??
Is this so that two separate reservations can share fate or policy limit?

> is {X|Y} when Alice thinks it is {A|B} and Carol thinks it is {C|D}.

True and good point.  I would note, though, that even if the info was "updated" and Alice starts using a new Session-ID, it doesn't cover everything because a REFER does not terminate a dialog.  The dialog to Bob still exists.  I think that's ok from your perspective because I think you're trying to make the Session-ID follow the dialog path with active media, right? 

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Nov 2011 16:44:50 +0000

Part-2 inline below...

> else meaningful.  But, that will be another WG and another charter ;-)

The big concern I have with anyone using the Session-ID for anything other than troubleshooting/logging, is that SBCs will invariably end up having to go change the Session-ID in certain call scenarios to purposefully be something that does not match both sides, simply to counter-act whatever clever mechanism someone's decided to use Session-ID for.  There are lots of reasons that could happen, from fixing bugs to fixing scenarios their clever scheme didn't take into account and breaks stuff for, to just plain not wanting the clever mechanism to happen due to some policy reasons.  If that happens, we lose the ability to use Session-ID for troubleshooting.

We've gone over examples of cases where that could happen in email threads of my earlier Session-ID drafts, which is why I ended up changing the drafts to *only* make it used for logging/troubleshooting.  

I know some people in the IETF don't care much about having a header value purely for troubleshooting correlation, but we hear this desire time and time again from the people who run/manage SIP networks. (I'm not saying you don't want that too - I'm just saying a header for troubleshooting alone is worth having)

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 16 Nov 2011 12:25:26 -0500

Hadriel,

> Is this so that two separate reservations can share fate or policy

Yes, that's one sort of thing we had in mind.  We also considered using it
to identify a PATH message as belong to a given call, since these two are
otherwise disjoint.
 
> True and good point.  I would note, though, that even if the info was
> "updated" and Alice starts using a new Session-ID, it doesn't cover
> everything because a REFER does not terminate a dialog.  The dialog to
> Bob still exists.  I think that's ok from your perspective because I
> think you're trying to make the Session-ID follow the dialog path with
> active media, right?

If I understand you correctly, I think it would be OK because when a device
is REFERRed somewhere, a new and different end-to-end Session ID would be
constructed.  In our proposal, we suggest the referred-party re-use its
Session-UUID for the call, as it helps to establish a trail.  However,
that's a nice bi-product of the approach we're taking and not a hard
requirement.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 16 Nov 2011 12:40:23 -0500

Hadriel,

> The big concern I have with anyone using the Session-ID for anything
> other than troubleshooting/logging, is that SBCs will invariably end up
> having to go change the Session-ID in certain call scenarios to
> purposefully be something that does not match both sides, simply to
> counter-act whatever clever mechanism someone's decided to use Session-
> ID for.  There are lots of reasons that could happen, from fixing bugs
> to fixing scenarios their clever scheme didn't take into account and
> breaks stuff for, to just plain not wanting the clever mechanism to
> happen due to some policy reasons.  If that happens, we lose the ability
> to use Session-ID for troubleshooting.

I would hope people do not introduce "clever" mechanisms.  I'd very much
like the rules to be well-defined.  Once the rules are defined, then we
could use Session-ID for other things, but I would not expect there to be
changes to SIP as a result.  For SIP, there should one and only one way of
signaling the Session-ID.  With those well-defined rules, then we should be
able to rely on it for other things, but I don't want to define those other
things yet.  If all we get is logging, then it's still worth the effort.  I
just hope we can use it more broadly.
 
> We've gone over examples of cases where that could happen in email
> threads of my earlier Session-ID drafts, which is why I ended up
> changing the drafts to *only* make it used for logging/troubleshooting.

If we work through use cases and hit a wall, that would be reason for
concern.  I do think we can make it work, though.  It would require
functionality on the B2BUA that decides to re-route calls, etc., but that
will happen with time.
 
> I know some people in the IETF don't care much about having a header
> value purely for troubleshooting correlation, but we hear this desire
> time and time again from the people who run/manage SIP networks. (I'm
> not saying you don't want that too - I'm just saying a header for
> troubleshooting alone is worth having)

So, aim high... :)

Paul