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

["Paul E. Jones" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Hutton, Andrew
> Sent: Tuesday, March 27, 2012 4:31 AM
> To: Hadriel Kaplan; Olle E. Johansson
> Cc: Paul E. Jones; <[e-mail]>
> Subject: Re: [Insipid] Session-ID : user or server controlled
> 
> 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
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Hadriel Kaplan
> > Sent: 26 March 2012 20:10
> > To: Olle E. Johansson
> > Cc: Paul E. Jones; <[e-mail]>
> > 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
> >
> > On Mar 26, 2012, at 6:49 PM, Olle E. Johansson wrote:
> >
> > >
> > > 26 mar 2012 kl. 18:47 skrev Paul E. Jones:
> > >
> > >> 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...
> > > Not a solution, sorry. In this application, I just need to manage it
> > from the man-in-the-middle-box.
> > >
> > > /O
> > >
> > >
> > >>
> > >> Paul
> > >>
> > >>> -----Original Message-----
> > >>> From: [e-mail] [mailto:[e-mail]]
> > >>> On
> > Behalf
> > >>> Of Olle E. Johansson
> > >>> Sent: Monday, March 26, 2012 10:46 AM
> > >>> To: [e-mail]
> > >>> Subject: [Insipid] Session-ID : user or server controlled
> > >>>
> > >>> 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
> > >>> _______________________________________________
> > >>> insipid mailing list
> > >>> [e-mail]
> > >>> https://www.ietf.org/mailman/listinfo/insipid
> > >>
> > >> _______________________________________________
> > >> insipid mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/insipid
> > >
> > > ---
> > > * Olle E Johansson - [e-mail]
> > > * Cell phone [phone], Office [phone], Sweden
> > >
> > >
> > >
> > > _______________________________________________
> > > insipid mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/insipid
> >
> > _______________________________________________
> > insipid mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/insipid
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid