Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Dec 2010 08:57:48 -0500

On 11/29/2010 3:07 PM, Hadriel Kaplan wrote:
>
> On Nov 29, 2010, at 9:12 AM, Paul Kyzivat wrote:
>
>> I find this very distressing:
>> ... [snip] ...
>> At Mastricht we had an informal meeting to discuss the possibility of
>> doing something similar to Behave for SBCs, but it went nowhere - there
>> was no consensus that anything meaningful could be done. But I think we
>> will continue to have problems like this one with session-id until we
>> find a way to confront this. ISTM we really need a "declaration of SIP
>> rights" that spells out the things that a well defined middle box will
>> not mess with. And it needs to be defined not as an enumeration of
>> already defined things, but rather as an algorithm that may be applied
>> to yet-to-be-defined things as well.
>
> The thing I find distressing is the continual belief that session-id (or any variant thereof) is tied to the SBC "problem" and crossing them.  Session-id isn't just about SBCs.  It's about PBX's, softswitches, app servers, feature servers, etc.  All kinds of things are B2BUAs and replace the call-id/tags on their UAC side.  If this were just about crossing SBC's, I wouldn't bother publishing something in the IETF.  Frankly, I'd call up three other vendors in the SBC market, and between us that would cover>90% of it.

Well, IIUC *you* are the one who stresses limiting the scope of 
applicability of session-id to "troubleshooting" *because* broadening 
its scope would encourage blocking propagation of the session-id.

> And if there were a push for a BEHAVE of SBCs, it would have to start off with not believing SBCs somehow restrict your "SIP rights".
> This isn't a NAT or Firewall you're silently crossing as a bump in the wire to reach the public Internet.
>  Your client sent its SIP request to the SBC, which is the UAS.  Your 
SIP ends there.

There is quite a difference between the case where you address a request 
to a URI that happens to be a B2BUA, and the case where you address the 
request to some URI and then route the request through an intermediary 
that turns out to act as an SBC rather than a proxy.

Then there is a fuzzy middle ground where you want to send a request to 
a phone number, but don't know or care what domain is responsible for 
that number, and so end up addressing it to a URI that turns out to be 
serviced by an intermediary, be that SBC or gateway.

ISTM the trick is to come up with a new notion of e2e that encompasses 
the presence of UA intermediaries, and some expectations of what can 
then be expected to survive e2e. And yes, that should cover 
intermediaries other than just SBCs.

> It's like telling me a SIP PSTN Gateway restricts your "SIP rights" because it doesn't pass some new SIP header through SS7/ISUP.
> Or telling me my SIP phone restricts your rights if my phone doesn't support REFER or Invite-Replaces from you.  You may not get a feature you want, but you have no inalienable "right" to get all features from any/every UAS you send a message to.
>
>
>> I'm curious if others feel this way, or am I just a lone raging lunatic?
>
> Is that an exclusive "or"?  ;)

I may be a raging lunatic, but I doubt I'm the lone one.
I can think of a number of candidates, but I'll keep that list to 
myself. :-)

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 1 Dec 2010 11:44:36 -0500

Hummm.  SIP Neutrality ..very timely. :-)  

	Thanks,
	Paul

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 01 Dec 2010 10:50:40 -0600

+1
It is actually long overdue.

>but rather as an algorithm

Is the key objective IMO.

Thanks, Henry
 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Laura Liess <[email-masked]>
Date: Fri, 3 Dec 2010 16:39:16 +0100

Paul,
I definitively like your idea.
However, something is needed for troubleshooting, which works also for
existing end devices which do not support the session-ID.   Hadriel's
draft does this. It would be great if we could find something which
works for both.

I understand that you are flexible about how Session-UUID is
transmiter (parameter in Contact or header) and about how the UUID is
calculated.

Another question on the draft:
 Why do you need to calculate the Session-UUID in both UAs?
Would it be sufficient that UA A inserts its UUID_A, sends it in the
INVITE to UA
B, then UA B adds its UUID_B and sends the new Session-UUID, which is
 UUID_B +UUID_A,  back to UA A in the 200 OK?

Thanks a lot
Laura

2010/11/30 Paul E. Jones <[email-masked]>:
>  Laura,
>
> I think it's good to overcome the weaknesses of both proposals.  However,
> what we could not understand is how Hadriel's draft would accommodate things
> such as joining two sessions together as a B2BUA.  This happens with
> enterprise PBXes, for example.  If A and B both have sessions established
> with C, then C joins those together in some way so that there is now a
> single session between A and B, what is the session ID?  The approach we
> suggest would accommodate that.

>
> Our proposal does hide the user's identity if random numbers are used for
> the UUIDs, which is a valid option when generating UUIDs.  We could also
> hash the values.
>
> Carrying the UUIDs inside a new header (e.g., Session-UUID) is also possible
> and, as I mentioned separately, was the way the first (pre-published) draft
> had it.
>
> The approach we propose will also work with H.323, which is something I
> intend to introduce there, too.
>
> What is not clear is how our proposal comes up short for the troubleshooting
> case.  I can see a situation where A (a device supporting Session-UUID)
> might call B (without this support) and then there's no way to get the
> complete Session ID for troubleshooting.  I don't see a solution for that
> case with our approach.
>
> I am not opposed to having two values going across the wire, though I would
> prefer to avoid that.  It gets really ugly when we have so may different
> kinds of identifiers flowing across the network.  It would be really good to
> have one solution that meets everyone's needs.
>
> What we want is to have a session ID that allows for calls to be
> transffered/joined/merged/etc. and to be able to still have an end-to-end ID
> all devices agree upon as call legs are moved around.  We'd also like to be
> able to use that ID to relate media flows with signaling flows (e.g., allow
> RTCP packets to contain the composed Session ID).  We would appreciate the
> ability to relate calls to a conference by taking note of shared UUID
> values.  We'd also appreciate the ability to take note of changes related to
> sessions (e.g., call joins) as UUID components change.
>
> Paul
>
> On 11/30/2010 10:38 AM, Laura Liess wrote:
>>
>> Sorry for the previous unfinished message. Here is the complete one.
>>
>>
>>  It seems that Hadriel's Session-ID for troubleshooting and the new
>>  UUID based Session-ID are almost complimentary concerning their pros
>>  and cons.
>>  a) Troubleshooting Session-ID:
>>         + Works for every kind of SIP-messages
>>         + External trubleshooting devices are able to correlate
>>  different segments of a call, also when the end device initiating the
>>  call does not support the Session ID.  The first B2BUA in the call
>>  constructs the Session-ID on behalf of the end device, as a hash of
>>  the Call-ID it receives  from the end device.
>>         + Hides the identity (and IP-address) of the end device
>>         -  Does not cover all use cases where dialog correlation is
>> needed.
>>
>>  b) UUID based Session-ID
>>        + Possibly covers all or most use cases where dialog
>>  correlation is needed.
>>        - Does not work for every kind of SIP-messages
>>        - External trubleshooting devices are not able to correlate
>>          different segments of a call when the end device initiating the
>>          call does not support the Session ID.
>>        - Does not hide  the identity (and IP-address) of the end device
>>
>> Hadriel's Session-ID is already up and running within many boxes.
>>
>> Maybe it is possible to find a solution which has the pros of both
>> proposals and is compatible with the already implemented Session-ID?
>> Just a thought, I am not sure it works: The first UA or B2BUA
>> calculates the Session-ID as described in Hadriel's draft. If it
>> supports the new mechanis, it concatenates the UUID to it and writes
>> the result into the Session-ID header.  The next UA adds its own UUID
>> to it if its supports the new mechanism ans so on. I think the
>> correlation for troubleshooting would work, and the correlation for
>> conferencing would work if the conference initiator supports the new
>> mechanism.  the Session-ID may be different for different messages of
>> the same call segment, but there we have the call-ID.
>>
>> Thanks a lot
>> Laura
>>
>>
>>> 2010/11/30 Paul E. Jones<[email-masked]>:
>>>>
>>>>  Hadriel,
>>>>
>>>> It's OK if the conference server does not know what UUID to send.
>>>>  Once
>>>> the user enters the conference details, the call might be transferred to
>>>> another device and/or just change state and dropped into an existing
>>>> conference.  Either way, a new INVITE would be sent from the conference
>>>> server to the remote endpoint with the new UUID.  This new UUID would
>>>> then
>>>> replace the previous value received.  At this point, the call could be
>>>> seen
>>>> as being part of the same conference.  UUID values from either endpoint
>>>> might change at any time due to transfers or replacement of "call legs"
>>>> that
>>>> are not necessarily signaled.  Either way, the Session ID is updated
>>>> through
>>>> the whole process.  Further, those who need to know the current Session
>>>> ID
>>>> would have that information, whether it is the endpoint or
>>>> intermediaries.
>>>>
>>>> To your points:
>>>> 1) Would a standalone MESSAGE be a part of a session?  Is this statement
>>>> true for MESSAGE sent as a part of a session? (You've got me on that
>>>> one.)
>>>>  In any case, we can most certainly send this as a new header like you
>>>> did
>>>> in your draft.  My first cut at this introduced a new header called
>>>> Session-ID-UUID.  It's a bit long, so I'd prefer Session-UUID.  But, I
>>>> definitely have no love for where we place the UUID or even whether its
>>>> a
>>>> UUID or not.  It could be an SHA-1 hash of random data for all I care:
>>>> just
>>>> want something that's "guaranteed" to be unique.
>>>> 2) Interesting.  I'll take your word on that, though I'm not sure why
>>>> one
>>>> place would be more challenging than another.
>>>> 3) People say this, though I never understood why.  That said, if one
>>>> wishes
>>>> to hide the MAC, there are procedures to generate UUIDs using random
>>>> numbers.  I forget off hand what UUID "version" that is, but there are
>>>> ones
>>>> with random digits.  In any case, we could create a version 0 UUID
>>>> (i.e.,
>>>> has the MAC) and then run that through a hash function like SHA-1.
>>>>
>>>> I'm certainly open to most aspects of the text.  Most importantly, I'd
>>>> like
>>>> to see progress on defining a session ID value we can use end-to-end in
>>>> the
>>>> spirit of what I've proposed, as I think it meets your requirements and
>>>> those I have.
>>>>
>>>> Paul
>>>>
>>>> On 11/29/2010 9:12 AM, Hadriel Kaplan wrote:
>>>>>
>>>>> Hi Paul,
>>>>>
>>>>> With regard to using the two-sided approach in order to handle
>>>>> conference
>>>>> call cases, this was discussed way back for the session-id draft as
>>>>> well...
>>>>> but the issue was that many/most conference servers don't actually know
>>>>> that
>>>>> multiple calls are part of the same conference until the user presses a
>>>>> conference code in DTMF, which is after the call is answered.  Do you
>>>>> expect
>>>>> the conference server to issue a re-INVITE in such cases, to transmit a
>>>>> new
>>>>> UUID for its side?
>>>>>
>>>>> With regards to specifics about the proposed mechanism:
>>>>> 1) Putting it in the Contact header means it won't work for MESSAGE
>>>>> requests, since they have no Contact; and it would be weird in a
>>>>> REGISTER
>>>>> which can have multiple Contacts.  At the end of the day, this ID isn't
>>>>> really a property of the Contact.
>>>>> 2) Putting it in the Contact header means it will be very difficult to
>>>>> get
>>>>> SBCs/B2BUAs to "leave it alone" without having to change their internal
>>>>> software, arguably more so than if it were in a separate header.
>>>>> 3) Using a UUID is not "safe", in the sense that it reveals a MAC
>>>>> address
>>>>> and therefore the vendor/manufacturer of the UA, so an SBC would be
>>>>> motivated to remove/replace this. (I know it's a minor concern, but
>>>>> some
>>>>> people do worry about this)
>>>>>
>>>>> -hadriel
>>>>>
>>>>>
>>>>> On Nov 28, 2010, at 5:23 PM, Paul E. Jones wrote:
>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> I want to bring to your attention this new draft some colleagues and I
>>>>>> put
>>>>>> together to try to address the need for a "session identifier" that
>>>>>> allows
>>>>>> for end-to-end session identification.  We also see utility that goes
>>>>>> beyond
>>>>>> just identifying the session end-to-end, as outlined in the document.
>>>>>>  We
>>>>>> believe this approach will satisfy those needs and do so in a very
>>>>>> simple,
>>>>>> straight-forward way.  Equally important, this approach will work with
>>>>>> SIP,
>>>>>> H.323, and other session signaling protocols.
>>>>>>
>>>>>> We welcome any feedback you'd like to provide.
>>>>>>
>>>>>> Thanks!
>>>>>> Paul
>>>>>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 03 Dec 2010 11:21:51 -0500

Laura,

If both end devices have no concept of a "Session-ID" or "Session-UUID" 
or other, then it makes no difference.  If either device supports either 
Session-ID or Session-UUID, then that alone could be used for 
troubleshooting purposes on the signaling path.  It would not be useful, 
though, to correlate signaling and media flows.

The reason for calculating a Session-UUID in both endpoints is so that 
the Session-ID would be the concatenation of these two generated UUIDs.  
This Session-ID could then be used in logging, RSVP, RTCP, or elsewhere 
in order to identify the session end-to-end.  Further, since sessions 
might be joined in the middle of the network by devices like B2BUAs, we 
cannot assume that one device or the other will generate "the" session 
ID.  We believe it must be something composed of information from both 
endpoints.

So, what we're proposing is that A sends Session-UUID in the INVITE.  
The remote end would return its Session-UUID in the reply.  It would not 
include two Session-UUIDs, as it's not necessary.  With the INVITE/200 
exchange, both endpoints know what the Session-ID is (as would any 
intermediary that has an interest).

During the course of the session, the call might be modified (silently 
redirected or joined to a different endpoint).  In such a case, a new 
INVITE might be sent from a B2BUA, for example, that contains a new 
Session-UUID.  The receiving endpoint would recognize this as a change 
in the Session-ID.  Indeed, the end-to-end session has changed.  This 
change would be noted by interested parties.

You suggested below that A sends UUID_A and that B sends UUID_A || 
UUID_B.  We could do this, but I'm not sure what value that offers.  A 
already knows its UUID_A and only needs to receive the value UUID_B.

Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 7 Dec 2010 14:10:15 -0500

This draft is intriguing...  In concept, it identifies something that we understand but have not named, the "end of a session", what is usually considered a call instance on a phone.  E.g., when phone B transfers caller A to talk to C, the "end of the session" at A does not change, despite that the A-B dialog has been replaced by the A-C dialog.  Indeed, the fact that we say one dialog "replaces" another at A means that the "end of the session" at A has not changed.  The draft proposes that UAs coin UUIDs to label each end of a session that they create.  Conference servers are a special case, in that each conference focus uses one end of a session UUID for all of the legs of the conference.

The draft proposes that each UA, in any INVITE, sends the end-of-the-session UUID at its end.

The draft proposes that each UA, when it learns the end-of-the-session UUID of the other end of a dialog, should combine that with its own end-of-the-session UUID to generate a "Session Identifier".

But there seem to be no places where the Session Identifier becomes manifest in the protocol.  So I'm not sure what its purpose is.

But getting back to the end-of-the-session UUID, that seems like it could be useful for troubleshooting, etc.  It's a close kin to the "References" header proposal, in that it gives a way to show within the signaling that two dialogs are associated.

It seems to have the same difficulties as Hadriel's session-id when it comes to having B2BUAs pass it through.

Dale

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 15 Dec 2010 16:56:32 -0500

Dale,

I apologize for not seeing your message sooner.

All of the points you mention are correct.  The important aspect of this
approach is, indeed, the fact that we can identify and end-to-end session as
the session is manipulated in the network.

The question you had was "what do we want to do with it?"  There are a
variety of things we would like to do with this, including associating SIP
signaling with media flows, billing logs, troubleshooting, etc.  It's true
that the final end-to-end session ID is not signaled as a single signaling
element, but each half is in the signaling going in each direction.

We might have challenges getting B2BUAs to pass it through, but I'm not sure
what to suggest, except that we work that out as a group.  It could be
signaled as we have it written in the draft now, or via its own header.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Worley, Dale R (Dale)
> Sent: Tuesday, December 07, 2010 2:10 PM
> To: [email-masked]
> Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-
> 00.txt
> 
> This draft is intriguing...  In concept, it identifies something that we
> understand but have not named, the "end of a session", what is usually
> considered a call instance on a phone.  E.g., when phone B transfers
> caller A to talk to C, the "end of the session" at A does not change,
> despite that the A-B dialog has been replaced by the A-C dialog.
> Indeed, the fact that we say one dialog "replaces" another at A means
> that the "end of the session" at A has not changed.  The draft proposes
> that UAs coin UUIDs to label each end of a session that they create.
> Conference servers are a special case, in that each conference focus
> uses one end of a session UUID for all of the legs of the conference.
> 
> The draft proposes that each UA, when it learns the end-of-the-session
> UUID of the other end of a dialog, should combine that with its own end-
> of-the-session UUID to generate a "Session Identifier".
> 
> But there seem to be no places where the Session Identifier becomes
> manifest in the protocol.  So I'm not sure what its purpose is.
> 
> But getting back to the end-of-the-session UUID, that seems like it
> could be useful for troubleshooting, etc.  It's a close kin to the
> "References" header proposal, in that it gives a way to show within the
> signaling that two dialogs are associated.
>