Subject: [Insipid] Session-ID : user or server controlled

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 26 Mar 2012 16:45:57 +0200

In the meeting today, I realized that we're talking about two very different use cases:

- A user controlled session ID like in the draft
- A server controlled session ID

For call center applications, I need a server controlled session ID I want to slap on a call coming in from the ISDN and keep as it traverses several b2buas. At that point I don't even know which "user" that will be an endpoint in the call and I don't really care.

Just to confuse a little bit more, if needed.

/O

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 26 Mar 2012 12:47:04 -0400

Coming in from the ISDN, that GW is the originating user agent as far as SIP
is concerned.  So, I think that's a reasonable place for the Session-ID UUID
to be created for one end.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Olle E. Johansson
> Sent: Monday, March 26, 2012 10:46 AM
> To: [email-masked]
> Subject: [Insipid] Session-ID : user or server controlled
> 
> For call center applications, I need a server controlled session ID I want
> to slap on a call coming in from the ISDN and keep as it traverses several
> b2buas. At that point I don't even know which "user" that will be an
> endpoint in the call and I don't really care.
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 26 Mar 2012 18:49:16 +0200

> to be created for one end.
But that is totally outside of my control. I will have to wait to a majority of the larger SIP providers in Europe support this then...
Not a solution, sorry. In this application, I just need to manage it from the man-in-the-middle-box.

/O

>> Just to confuse a little bit more, if needed.

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 26 Mar 2012 14:09:13 -0400

Olle,

> > Coming in from the ISDN, that GW is the originating user agent as far
> > as SIP is concerned.  So, I think that's a reasonable place for the
> > Session-ID UUID to be created for one end.
> But that is totally outside of my control. I will have to wait to a
> majority of the larger SIP providers in Europe support this then...

My mail server will insert a Message-ID header if one is not present in the
incoming message headers.  I believe it would be reasonable to do the same
for this identifier.  If it's not present, a middlebox could insert it.  It
might mean that the ISDN GW would be oblivious to the Session-ID, but it's a
starting point to getting something.  At least everything beyond the
middlebox would have a common understanding of the identifier.

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Mar 2012 18:10:17 +0000

[as an individual]

I don't see it in draft-jones-insipid-session-id-00 yet, but draft-kaplan-dispatch-session-id-03 had the notion that a B2BUA could generate a Session-ID if none was in the received request.  This was to provide a migration path for cases where the originating UAC (softphone, gateway, whatever) did not yet support Session-ID and thus did not generate it itself. (and likewise the B2BUA inserts it in the response if the UAS did not support Session-ID and did not reflect it in its responses)

-hadriel

---

From: Laura Liess <[email-masked]>
Date: Mon, 26 Mar 2012 21:51:15 +0200

We already have the REQ7 to cover situations when end devices do not
support the Session-ID. (We know from experience that users often
don't allow updates for their end devices.) It would be reasonable to
extend this requirement for PSTN-Gateways and even for the general
case when an incoming SIP-request does not contain a Session-ID (e.g.
when the sending domain does not support it yet).

As Hadriel already said, the mechanism proposed in the kaplan-draft
satisfies this requirement by taking the incoming Call-ID and hashing
it. (The hash is to satisfy REQ5.)

Thanks,
Laura

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 27 Mar 2012 10:31:19 +0200

I am thinking that we also need to consider 3PCC scenarios in which the B2BUA effectively initiates the two legs in this case the B2BUA is going to generate the session-id when it generates the initial INVITE request.

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hadriel Kaplan
> Sent: 26 March 2012 20:10
> To: Olle E. Johansson
> Cc: Paul E. Jones; <[email-masked]>
> Subject: Re: [Insipid] Session-ID : user or server controlled
> 
> 
> [as an individual]
> 
> I don't see it in draft-jones-insipid-session-id-00 yet, but draft-
> kaplan-dispatch-session-id-03 had the notion that a B2BUA could
> generate a Session-ID if none was in the received request.  This was to
> provide a migration path for cases where the originating UAC
> (softphone, gateway, whatever) did not yet support Session-ID and thus
> did not generate it itself. (and likewise the B2BUA inserts it in the
> response if the UAS did not support Session-ID and did not reflect it
> in its responses)
> 
> -hadriel
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 27 Mar 2012 08:45:25 +0000

Andy,

I agree with you for 3PCC scenario. IMO, Paul Jones session-id serves the purpose as each UA attach their own URN UUID. 

Thanks
Partha

Note: Paul Jones Session-id shall be considered as concatenation of participant URN UUID in SIPREC terms

>Behalf Of Hutton, Andrew
>Sent: Tuesday, March 27, 2012 2:01 PM
>To: Hadriel Kaplan; Olle E. Johansson
>I am thinking that we also need to consider 3PCC scenarios in which the
>B2BUA effectively initiates the two legs in this case the B2BUA is going
>to generate the session-id when it generates the initial INVITE request.
>
>Regards
>Andy
>
>> generate a Session-ID if none was in the received request.  This was
>> to provide a migration path for cases where the originating UAC
>> Behalf
>> >>> For call center applications, I need a server controlled session
>> >>> ID
>> I want

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Mar 2012 12:04:35 -0400

It seems there is general agreement with that point.  We had inserted it
into the requirements as REQ7, but we had not covered that in
draft-jones-insipid-session-id.  We should have, though.  Indeed, I expect
that phones connected to a PBX may or may not generate a UUID (depending on
the date of their firmware) to generate these UUIDs, but we would certainly
want the network to benefit from being able to track a session at least to
the PBX, if not to the phone.

Paul

> Of Hutton, Andrew
> Sent: Tuesday, March 27, 2012 4:31 AM