Re: [Insipid] draft-kaplan-insipid-session-id: parameters and session-id

[Brett Tate <[e-mail]>]

Hi,

Thanks for the responses.  I'm asking the questions to better understand and evaluate draft-ietf-insipid-session-id from a backward compatibility perspective with draft-kaplan-insipid-session-id.  I look forward to the next version of draft-ietf-insipid-session-id since it might provide answers to my questions (at least from insipid perspective interacting with a draft-kaplan-insipid-session-id device).

One of the call flows of interest is associated with B2BUA acting as 3PCC simulating call waiting type interaction (similar to RFC 3725 figure 13 if assume message 6 is a re-INVITE) using re-INVITE (from B2BUA) to reconnect an insipid device (X) back and forth between connections with insipid device (I) and kaplan device (K).  My current understanding is that X theoretically might change remote value and include parameter changes (new, dropped, or modified).  Thus from a B2BUA perspective, I'd need to know how draft-ietf-insipid-session-id proposes the B2BUA behave to allow backward compatibility with K.  For instance, should it send the completely new Session-ID header (i.e. new sess-id and parameters) to K or continue to send the prior Session-ID header (such as the Session-ID used when dialog created)?  Should prior knowledge of K's non support of draft-ietf-insipid-session-id cause the B2BUA to not include a draft-ietf-insipid-session-id Session-ID within the re-invite sent to X?

Thanks,
Brett

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of DRAGE, Keith (Keith)
> Sent: Tuesday, November 05, 2013 4:15 PM
> To: Paul Kyzivat; [e-mail]
> Subject: Re: [Insipid] draft-kaplan-insipid-session-id: parameters and
> session-id
> 
> Personally I'd probably follow 4.3, but if both sides are operating
> correctly, there should not be a conflict.
> 
> To add to Paul's discussion points, it is also a question of whether
> any ambiguity causes misoperation.
> 
> Keith
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> > Sent: 05 November 2013 21:02
> > To: [e-mail]
> > Subject: Re: [Insipid] draft-kaplan-insipid-session-id:
> > parameters and session-id
> >
> > Brett,
> >
> > Since the kaplan draft is effectively historical, intended to
> > document something that has already been implemented, its not
> > evident to me that asking clarifying questions about it is
> > useful. If you have those questions, then the implementers of
> > it must have had them too, or failed to realize the ambiguity.
> >
> > I think the only things it is helpful to consider are:
> > - what behaviors would be plausibly compliant with kaplan?
> > - what do actual known implementations of kaplan actually do?
> >
> > 	Thanks,
> > 	Paul
> >
> > On 11/5/13 8:14 AM, Brett Tate wrote:
> > > Hi,
> > >
> > > Concerning the topic of backward compatibility with
> > draft-kaplan-insipid-session-id, I'm not sure that I
> > understand sections 4.2 and 4.3 of
> > draft-kaplan-insipid-session-id-03 concerning parameters and
> > Session-ID header modifications.
> > >
> > > Section 4.2 indicates:
> > > "The UAC MUST re-use the same Session-ID value for
> > in-dialog messages
> > >   as that of the original dialog-creating request".
> > >
> > > Section 4.3 indicates:
> > > "A UAS compliant with this document MUST copy a received Session-ID
> > >   header field in a request, into responses and subsequent upstream
> > >   requests sent within the dialog."
> > >
> > > What should the generator of the Session-ID (from section
> > 4.2 perspective) do if receives mid-dialog Session-ID header
> > modification within a request?
> > >
> > > 1) Follow section 4.2 MUST.
> > > 2) Follow section 4.3 MUST.
> > > 3) It is abnormal situation; thus it can do whatever it wants.
> > >
> > > What if there is only a parameter modification: added,
> > removed, or value change?
> > >
> > > What should the generator of the Session-ID (from section
> > 4.2 perspective) do if receives Session-ID header
> > modification within a response?
> > >
> > > Concerning the section 4.2 and 4.3 snippets, my
> > understanding is that the MUST includes parameters (instead
> > of just Session-ID's sess-id).  Is my interpretation correct?
> >  I thought that I'd ask to ensure that I'm not
> > misinterpreting the use of "value" and "field".
> > >
> > > Thanks,
> > > Brett