Subject: Re: [siprec] Session-id in SIPREC [Was RE: [RAI] Minutes of 3GPP - IETF telco on the 19th of October]

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 1 Nov 2010 14:14:44 +0530

As the starting time for the discussion, I attached 4 usecase and
requirement for SIPREC unique identifier. The usecases are

1) Two party basic callflow of SRC co-located in B2BUA 
2) Two party call transfer flow of SRC co-located in UA
3) Three party conference call flow of SRC co-located in UA
4) Two party call transfer of SRC co-located in B2BUA

Please provide your valuable comments on the document. I'll update the
document based on the discussion in the e-mail thread.

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, October 28, 2010 6:59 PM
To: Parthasarathi R (partr); Hadriel Kaplan
Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked]; Ram Mohan R
(rmohanr); Ken Rehor (krehor)
Subject: RE: Session-id in SIPREC [Was RE: [RAI] Minutes of 3GPP - IETF
telco on the 19th of October]

Partha,

Thanks for offering to work on this. If there has been good discussion
between now and Beijing, and if there are issues to discuss, we can bash
the agenda to make room.

John

> -----Original Message-----
> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: 28 October 2010 12:36
> To: Elwell, John; Hadriel Kaplan
> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked]; Ram Mohan 
> R (rmohanr); Ken Rehor (krehor)
> Subject: RE: Session-id in SIPREC [Was RE: [RAI] Minutes of 3GPP - 
> IETF telco on the 19th of October]
>
> John,
>
> I'm of the same opinion that unique identifier mechanism will be 
> outside the scope of SIPREC.
>
> ram-siprec-metadata model indicates the unique identifier as an one 
> parameter in CS or CS group. Till now, metadata model is based on 
> usecase and requirement in siprec-req. IMO, It will not provides 
> usecases related to this unique identifier. Paul & Ram, Please correct

> me in case I'm wrong.
>
> I had request lot of times for usecase document for the session 
> id/SIPSCOTCH in Dispatch and send couple of usecase related to the 
> same.
> Most of the usecases are related to SIPREC as well. I'll come up with 
> usecases text and let us discuss in SIPREC through mailing alias & 
> during IETF-79 meeting. Based on the discussion, Let us decide whether

> it is required to have separate draft or adding it in any one of the 
> existing SIPREC draft. Please let me know your opinion on the same.
>
> Please read inline for more comments
>
> Thanks
> Partha
>
> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
> Sent: Thursday, October 28, 2010 3:42 PM
> To: Parthasarathi R (partr); Hadriel Kaplan
> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked]; Ram Mohan 
> R (rmohanr); Ken Rehor (krehor)
> Subject: RE: Session-id in SIPREC [Was RE: [RAI] Minutes of 3GPP - 
> IETF telco on the 19th of October]
>
> Partha,
>
> Hadriel's SIPSCOTCH proposal address the problem of a single 
> identifier for the same call on both sides of a B2BUA such as an SBC. 
> I get the impression that what De Villiers is asking for is a means of

> tying together two calls that are somehow linked, e.g., one arising 
> from the transfer of the other. The two calls would typically involve 
> the same remote party (a customer say), but the requirements are 
> subtly different, e.g., tying together two calls on the same side of 
> an SBC, as opposed to tying together two halves of a call passing 
> through an SBC.
> It could be that the same solution will work for both (although I 
> understand Hadriel's concerns, I think), but we have not really 
> documented the problem in detail. For example, if agent A makes a 
> consultation call to agent B, should that also have the same ID as the

> original call and/or the call that eventually results from transfer?
>
> <Partha> This is one of the 3PCC usecase where the current session-id 
> solution will not work. </Partha>
>
> So in my opinion we need more - whether that can go straight into 
> siprec-req, whether it needs to go into ram-siprec-metadata, or 
> whether it merits its own draft, I am not sure. However, it is quite 
> likely that it would require a mechanism that would be outside the 
> scope of SIPREC to specify, and hence having problem statement and 
> requirements in a separate draft might be helpful.
>
> John
>
> > -----Original Message-----
> > From: Parthasarathi R (partr) [mailto:[email-masked]]
> > Sent: 28 October 2010 09:59
> > To: Elwell, John; Hadriel Kaplan
> > Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked];
> Ram Mohan
> > R (rmohanr); Ken Rehor (krehor)
> > Subject: Session-id in SIPREC [Was RE: [RAI] Minutes of 3GPP
> > - IETF telco on the 19th of October]
> >
> >
> > John,
> >
> > As discussed in the attached mail thread, B2BUA acts as SRC and SRC 
> > has to inform the set of  communication session using an unique 
> > identifier, it can't be call-id and the proposal is to use
> session-id.
>
> > In case you feel that the requirement and usecase is not clear from 
> > SIPREC perspective, We will add the requirement & usecase in SIPREC 
> > requirement document itself. Please clarify whether separate ID is 
> > required for this unique recording id requirement?
> >
> > I like to hear from you whether two SRC for the single communication
> > session(CS) is outside the scope of SIPREC or not. Because,
> Recording
> > session group in metadata model is removed  from metadata
> draft that
> > two SRC for single CS is outside the scope of SIPREC.
> >
> > Thanks
> > Partha
> >
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]]
> > Sent: Thursday, October 28, 2010 1:22 PM
> > To: Parthasarathi R (partr); Hadriel Kaplan
> > Cc: Paul Kyzivat (pkyzivat); [email-masked]; Rosen, Brian
> > Subject: RE: [RAI] Minutes of 3GPP - IETF telco on the 19th
> of October
> >
> > Partha,
> >
> > First, as an individual, I am quite keen to see Hadriel's draft 
> > progress, even if its scope is limited to troubleshooting.
> >
> > Second, as SIPREC chair, it is unclear to me that we have
> in SIPREC a
> > clear problem statement. For example, one form of the
> problem that I
> > could imagine is that two session recording clients (one
> located at a
> > first agent, say, and the other located at a second agent,
> say) both
> > generate recording sessions to a session recording server to record 
> > what are two separate communication sessions from the
> perspective of
> > the two clients. However, the communication sessions are
> linked (i.e.,
>
> > part of the same thread) - perhaps the second session resulted from 
> > transfer of the first session from the first agent to the second 
> > agent.
> > Some form of
> > ID is needed to correlate the two recordings when they reach the 
> > session recording server. This is one possible form of the
> problem -
> > it may or may not be a valid problem and it may or may not be the 
> > total problem concerning session IDs and SIPREC.
> >
> > I would like to see discussion of the problem statement on
> the SIPREC
> > mailing list, and ideally I would like to see an I-D on the
> subject (I
>
> > think we need more than what we have in siprec-req). If we have a 
> > clear problem statement and requirements, then we can attempt to 
> > address the problem either in SIPREC or elsewhere in RAI, as 
> > appropriate. In my opinion it is too early to say whether Hadriel's 
> > draft fulfils a SIPREC need.
> >
> > John
> >
> > > -----Original Message-----
> > > From: Parthasarathi R (partr) [mailto:[email-masked]]
> > > Sent: 28 October 2010 07:21
> > > To: Hadriel Kaplan
> > > Cc: Paul Kyzivat (pkyzivat); [email-masked]; Elwell, John
> > > Subject: RE: [RAI] Minutes of 3GPP - IETF telco on the 19th
> > of October
> > >
> > > Hadriel,
> > >
> > > I'm reading your mail like IETF has to add "n" number of
> > correlation
> > > id header based upon the usage.  we need to create the
> > correlation id
> > > like troubleshoot-id: xxxxx,
> > > recording-cs-id: xxxxxx individually. In case everybody
> > feels so, I'm
> > > fine with the approach.
> > >
> > > Still, I'm not getting your concern w.r.t SIPREC
> correlation id and
> > > why SIPREC session id will not be passed across in SIP
> devices but
> > > trouble-shoot-id will? Please elaborate in this mail thread or in 
> > > SIPREC IETF alias.
> > >
> > > In my experience with unique SIP session identification
> > (cisco-guid),
> > > the current proposed "session-id" will not work for
> number of 3PCC
> > > callflows. In case you feel that troubleshoot id for 3PCC
> > callflow has
> >
> > > to be based on another
> > > troubleshoot-id-part-2 ;-) Then it requires more
> discussion in IETF.
> > >
> > > Thanks
> > > Partha
> > >
> > >
> > > ________________________________
> > >
> > > From: Hadriel Kaplan [mailto:[email-masked]]
> > > Sent: Thursday, October 28, 2010 10:52 AM
> > > To: Parthasarathi R (partr)
> > > Cc: Paul Kyzivat (pkyzivat); [email-masked]; 
> > > [email-masked]
> > > Subject: Re: [RAI] Minutes of 3GPP - IETF telco on the 19th
> > of October
> > >
> > >
> > >
> > > If you don't want to implement support for passing through a 
> > > session-id header, then don't.  No one's making you.
> We're talking
> > > about an RFC, not a Biblical commandment.  There are a
> boat-load of
> > > RFC's no one's ever implemented.
> > >
> > > It's not the be-all-end-all final solution for world hunger.
> > > It's just one header.  It's one tool in a bag of tools.
> > >
> > > If some vendors support passing a session-id header and
> > other's don't,
> >
> > > it won't be as useful as it could have been.
> > > My customers tell me such a header would help them.  Maybe
> > I'm naive,
> > > but I would think when customers tell their vendors to do
> > something,
> > > the vendors generally try to do it.
> > > Especially if it's trivial to implement and helps the vendors
> > > *themselves* with supporting the customers in TAC.  So my
> belief is
> > > the market will decide if session-id succeeds - customers
> > will either
> > > want it, or not.  Meanwhile, all it takes to find out is to
> > publish a
> > > fairly simple RFC.  If it fails, we've wasted some IETF
> > people's time
> > > and an RFC number.  If it succeeds, we've made SIP a little
> > bit easier
> >
> > > to manage, for all of us.
> > >
> > > SIPCLF is orthogonal to session-id, really. In fact, one
> would hope
> > > the session-id would be recorded in SIPCLF as well.  Had we
> > published
> > > session-id when it was initially proposed, it would have been 
> > > available in time for SIPCLF to make a mandatory field.
> > >
> > > As for SIPREC, that's exactly the problem: I already *know*
> > of cases
> > > where we'll need to remove whatever correlation id siprec ends up 
> > > using.  Overloading this header for such things is just bound to 
> > > reduce its troubleshooting value, because we'll need to remove or 
> > > change it.  But that's *OK* - we have no shortage of header names 
> > > available in SIP ABNF.
> > > They can go define whatever new header-name they'd like,
> > with another
> > > value.
> > >
> > > -hadriel
> > >
> > > On Oct 27, 2010, at 11:30 PM, Parthasarathi R (partr) wrote:
> > >
> > >
> > >                       Hadriel,
> > >               SBC removing the header in the incoming SIP
> > message and
> > > forming the new outgoing message is the default behavior
> and it is
> > > nothing to do with session-id proposal.
> > > Session-id IETF RFC will help SBC to design for passing
> across the
> > > specific header in the forthcoming release. Which
> > forthcoming release
> > > (after 3 years or 10 years) depends upon the compelling
> reason for
> > > this header in specific SBC or other SIP device as we have
> > number of
> > > SIP RFC today to implement.
> > >               AFAIK, most of the companies create their
> own unique
> > > session id to identify the session and using it within
> > their network
> > > for different purposes. Standardizing session id SIP header
> > makes all
> > > the companies to interop in case the purpose of the
> > specific company's
> >
> > > unique session id is not broken. IMO, troubleshooting is
> one of the
> > > usecase which has workaround by building the appropriate logging 
> > > mechanism and tools to analyze the log across the device. I
> > guess that
> >
> > > SIPCLF WG addresses this requirement. If troubleshooting is
> > the only
> > > scope of the session-id, the adaptability of this header
> will take
> > > long time or may not take place in case the company
> provides better
> > > means for troubleshooting.
> > >               In case of SIPREC, the multiple
> communication session
> > > has to be related together in a single recording session
> using the
> > > unique id. Most of the folks in SIPREC mailing alias thinks that 
> > > session-id in communication session will serve the purpose.
> > IMO, the
> > > usability of the session-id has to be extended and it has to be 
> > > generic rather than specific service or application.
> > >               As I mentioned in the earlier mail thread
> > with RE-INVITE
> >
> > > based transfer in B2BUA usecase, session-id in the current
> > form will
> > > not serve the purpose for troubleshooting as well. Cisco has the 
> > > header similar to session-id which is named as "cisco-guid"
> > which has
> > > the issue in handling the mentioned usecase. We need to find the 
> > > better solution for session-id.
> > >               Thanks
> > >       Partha
> > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > >       From: Hadriel Kaplan [mailto:[email-masked]]
> > >       Sent: Wed 10/27/2010 7:35 PM
> > >       To: Parthasarathi R (partr)
> > >       Cc: Paul Kyzivat (pkyzivat); [email-masked]
> > >       Subject: Re: [RAI] Minutes of 3GPP - IETF telco on
> > the 19th of
> > > October
> > >
> > >
> > >
> > >
> > >       I'm not sure which way you mean this - do you mean
> if I don't
> > > get this published as an IETF RFC then SBC's will remove
> > it, or do you
> >
> > > mean even if we go define this as an IETF RFC SBC's will
> > still remove
> > > it?
> > >
> > >       I'm fairly confident that if it's published as an
> IETF RFC in
> > > its current form then SBC's won't remove it - or they
> will provide
> > > upgrades to not remove it.  I believe that because in my
> experience
> > > SBC's do what their owners/operators want them to do.  Whether 
> > > specific operators/admins decide to have their SBCs remove
> > it or not
> > > remains to be seen, but if it's useful for troubleshooting
> > while not
> > > harmful then my guess is they'll want the session-id to be passed 
> > > through.
> > > IF it causes any call failures, then they'll block it,
> which is why
> > > I'm so concerned about expanding the scope of it to other
> > things than
> > > troubleshooting.
> > >
> > >       If it's not published as an IETF RFC, then its less
> likely to
> > > succeed in the marketplace.  I could just take it to 3gpp,
> > but I was
> > > hoping to make this useful in non-IMS networks as well, such as 
> > > Enterprise.
> > >
> > >       -hadriel
> > >
> > >
> > >       On Oct 27, 2010, at 5:50 AM, Parthasarathi R (partr) wrote:
> > >
> > >       > Hadriel,
> > >       >
> > >       > In terms of SIP SBC, any unique ID or header or
> > body will be
> > > removed or
> > >       > modified whether it is for troubleshooting or for
> any other
> > > application
> > >       > purpose.
> > >       >
> > >       > Let us take the troubleshooting application itself.
> > > What is the
> > >       > requirement for Enterprise SBC to pass the
> > troubleshooting-id
> > > to service
> > >       > provider network in case SBC acts as UA or IMS UE
> > to service
> > > provider
> > >       > network? Being the border element, SBC may wish to
> > put the new
> > >       > troubleshooting id (hiding session-id) to the
> > outgoing dialog
> > > for the
> > >       > same session rather than passing the existing
> > troubleshooting
> > > id.
> > >       >
> > >       > I agree that the unique identification for the session is 
> > > required in
> > >       > different SIP application for different requirements.
> > > I'm seeing lot of
> > >       > requirement in Enterprise deployment other than 
> > > troubleshooting and
> > >       > also, noticed the unique-id requirement in SIPREC
> > to identify
> > > the group
> > >       > of communication session.
> > >       >
> > >       > Until otherwise SBC or any other middle box
> > > (B2BUA/Focus) decides to
> > >       > pass the specific header(s) based on standard, this
> > unique-id
> > > approach
> > >       > will never fly.
> > >       >
> > >       > Thanks
> > >       > Partha
> > >       >
> > >       > -----Original Message-----
> > >       > From: [email-masked] [mailto:[email-masked]] 
> > > On Behalf Of
> > >       > Paul Kyzivat (pkyzivat)
> > >       > Sent: Tuesday, October 26, 2010 9:44 PM
> > >       > To: [email-masked]
> > >       > Subject: Re: [RAI] Minutes of 3GPP - IETF telco on
> > the 19th of
> >
> > > October
> > >       >
> > >       > ISTM there is a Catch-22 here.
> > >       >
> > >       > If an ID is potentially of use for more than one
> > purpose, some
> >
> > > middlebox
> > >       > wants to mess with it in regard to one of those purposes.
> > > (Block it,
> > >       > make it work "better", etc.) Hence the only
> solution is to
> > > create a
> > >       > separate ID for each and every possible use. :-(
> > >       >
> > >       >        Thanks,
> > >       >        Paul
> > >       >
> > >       > On 10/26/2010 11:39 AM, Hadriel Kaplan wrote:
> > >       >>
> > >       >> The problem with using session-id for anything else
> > > is: for every
> > >       >> other use-case discussed so far, I can easily imagine 
> > > situations where
> > >       >
> > >       >> a middlebox would need to change the session-id to make 
> > > things work,
> > >       >> thereby negating its troubleshooting value.
> > >       >>
> > >       >> -hadriel
> > >       >>
> > >       >> On Oct 26, 2010, at 10:59 AM, Peter Musgrave wrote:
> > >       >>
> > >       >>> Hi Hadriel,
> > >       >>>
> > >       >>> I have implemented this as well. It has utility in a 
> > > non-trouble
> > >       >>> shooting context in my application.
> > >       >>>
> > >       >>> I think the issue in IETF was that we fell into
> > the "solve
> > > world
> > >       >>> hunger" trap. SIPREC through they might find it
> > useful for
> > > session
> > >       >>> correlation but in a pure SIP sense this
> > mechanism does not
> > > guarantee
> > >       >
> > >       >>> dialog correlation...
> > >       >>>
> > >       >>> Peter Musgrave
> > >       >>>
> > >       >>> On Tue, Oct 26, 2010 at 10:38 AM, Hadriel Kaplan
> > >       >>> <[email-masked]
> > > <mailto:[email-masked]>> wrote:
> > >       >>>
> > >       >>>
> > >       >>>    Hi,
> > >       >>>    I see the topic of session-id and SIPSCOTCH came
> > > up in this
> > >       >>>    meeting. I've tried getting it chartered, but it
> > > appears there
> > >       >>>    isn't consensus that the narrow topic I want
> > to focus on
> > >       >>>    (troubleshooting) is what other people care about.
> > >       >>>    (well... not for people in the IETF anyway - I
> > > get constant
> > >       >>>    queries about this draft mechanism from service
> > > providers, but
> > >       >>>    they don't generally join nor comment in IETF
> > > mailing lists)
> > >       >>>
> > >       >>>    So I don't really know what to do, other than
> > > just implement it
> > >       >>>    and convince some other vendors to as well, and
> > > avoid the IETF.
> > >       >>>    The IETF just isn't a good place for dealing
> > > with operational
> > >       >>>    issues in SIP, afaict.
> > >       >>>
> > >       >>>    -hadriel
> > >       >>>
> > >       >>>
> > >       >>>    On Oct 22, 2010, at 9:32 AM,
> > <[email-masked]
> > >       >>>    <mailto:[email-masked]>>
> > > <[email-masked]
> > >       >>>    <mailto:[email-masked]>> wrote:
> > >       >>>
> > >       >>>>    Dear all,
> > >       >>>>    please find the minutes of the 3GPP - IETF
> > > telco earlier this
> > >       > week.
> > >       >>>>    *Date:*19^th October 2010
> > >       >>>>    *Time:*15:00 - 17:00 UTC
> > >       >>>>    *Venue:*Phone conference
> > >       >>>>    *Participants:*
> > >       >>>>    Hannu Hietalahti (notetaker), Atle Monrad,
> > > Peter Schmitt,
> > >       >>>>    Christer Holmberg, Peter Dawes, Bengt Sahlin,
> > > Keith Drage, Milan
> > >       >>>>    Patel, Georg Mayer,
> > >       >>>>    Robert Sparks, Adam Roach, Dale Worley, Spencer
> > > Dawkins, Dan
> > >       >>>>    Romascanu, Jari Arkko, Paul Kyzivat, Ben Campbell
> > >       >>>>    *Agenda:*
> > >       >>>>    -------------
> > >       >>>>    1. Roll call
> > >       >>>>    2. Review of action points
> > >       >>>>    3. ATOCA work
> > >       >>>>    - Presentation of 3GPP PWS in IETF #79
> > >       >>>>    4. Stalled drafts
> > >       >>>>    - draft-drage-sipping-rfc3455bis
> > >       >>>>    - draft-ietf-patel-ecrit-sos-parameter
> > >       >>>>    - draft-ietf-sipcore-location-conveyance
> > >       >>>>    - draft-ietf-sipcore-keep
> > >       >>>>    - draft-ietf-sipcore-199
> > >       >>>>    - draft-bliss-call-completion
> > >       >>>>    - draft-ietf-mmusic-ice-tcp
> > >       >>>>    - draft-patel-dispatch-cpc-oli-parameter
> > >       >>>>    - draft-bakker-sipping-3gpp-ims-xml-body-handling
> > >       >>>>    - draft-kaplan-dispatch-session-id
> > >       >>>>    - draft-dawes-dispatch-mediasec-parameter?
> > >       >>>>    5. Review of 3GPP IETF dependency document
> > >       >>>>    - any comments on any other items in the
> > dependency list
> > >       >>>>    6. Next meeting
> > >       >>>>    7. AOB
> > >       >>>>    8. Closing
> > >       >>>>    *1. **ROLL CALL*
> > >       >>>>    All participants are listed above.
> > >       >>>>    *2. **REVIEW OF ACTION POINTS*
> > >       >>>>    *#*     *Old APs from previous meetings*
> > > *Responsible*
> > >       > *Status*
> > >       >>>>    14      Talk with ECRIT chairs and Robert
> > > Sparks to make a
> > >       > proposal on
> > >       >>>>    how and where the sos-parameter -draft
> should progress
> > >       >>>>    The current version is being reviewed in
> > > DISPATCH and then
> > >       >>>>    foreseen to proceed as AD sponsored draft
> > >       >>>>            Gonzalo         Closed
> > >       >>>>    15      Request for volunteers from 3GPP side
> > > to co-author
> > >       >>>>    draft-mmusic-ice-tcp    Atle    Closed
> > >       >>>>    16      Check with 3GPP LS officer why the LS
> > > C1-101810 was not
> > >       >>>>    distributed on DISPATCH list
> > >       >>>>    One way forward would be to provide an
> > > informational draft to
> > >       >>>>    document how things have been done
> > > historically. It was agreed
> > >       >>>>    that re-distribution of the LS is not necessary.
> > >       >>>>            Hannu   Closed
> > >       >>>>            *New APs assigned in this meeting*
> > >       >>>>    17      Agree during IETF #79 how to progress
> > > the work on
> > >       >>>>    draft-drage-sipping-rfc3455bis  Keith,
> > > Christer, Robert Open
> > >       >>>>    18      Decide between the editor, DISPATCH
> > > co-chairs and AD the
> > >       > best
> > >       >>>>    approach to progress the work on
> > >       >>>>    draft-patel-dispatch-cpc-oli-parameter.
> > > Milan, Mary,
> > >       > Cullen,
> > >       >>>>    Robert  Open
> > >       >>>>
> > >       >>>>
> > >       >>>>
> > >       >>>>    *3. ATOCA**WORK*
> > >       >>>>    Outside this meeting it has been agreed with
> > > ATOCA WG chairs
> > >       > that
> > >       >>>>    Hannu Hietalahti will make a presentation of
> > > 3GPP Public Warning
> > >       >>>>    System in the ATOCA session in IETF #79. The
> > > presentation is
> > >       >>>>    being prepared in small expert group. The
> > > drafting group does
> > >       > not
> > >       >>>>    follow any 3GPP WG borders but anyone who is
> > > willing to work on
> > >       >>>>    the presentation is invited to contact Hannu.
> > >       >>>>    *4. STALLED DRAFTS*
> > >       >>>>    *4.1 draft-drage-sipping-rfc**3455bis*
> > >       >>>>    This draft has been stalled due to low priority
> > > to drive it from
> > >       >>>>    3GPP side. Christer Holmberg volunteered to
> > help out as
> > >       > co-editor
> > >       >>>>    to get the work done.
> > >       >>>>    It still needs to be agreed how to progress
> > > this draft. AP 17
> > >       > was
> > >       >>>>    assigned to determine whether it can proceed as
> > > AD sponsored
> > >       > draft?
> > >       >>>>    *4.2 draft-ietf-patel-ecrit-sos**-parameter*
> > >       >>>>    Extensibility mechanism has been removed and
> > > now it is reversed
> > >       >>>>    back to just URI parameter to indicate
> > > emergency registration.
> > >       >>>>    The latest draft does not take any position on
> > > how the special
> > >       >>>>    registration would be treated afterwards.
> > Misuse of URI
> > >       > parameter
> > >       >>>>    is covered in the latest version, aiming at
> > > restricting the use
> > >       >>>>    of the special registration to emergency case only.
> > >       >>>>    The 3GPP requirement is to identify special
> > > registration for
> > >       >>>>    emergency purposes.
> > >       >>>>    Possible re-naming of the draft was discussed
> > > to highlight that
> > >       >>>>    it has been recently treated in DISPATCH but no
> > > firm decision
> > >       > was
> > >       >>>>    made on this yet.
> > >       >>>>    *4.3 draft-ietf-sipcore-location-conveyance*
> > >       >>>>    Authors intend to distribute a new version
> > > before IETF #79 to
> > >       >>>>    address the open issues that were identified in
> > > IETF #78 in
> > >       >>>>    Maastricht. The new version will be discussed
> > > in Beijing IETF.
> > >       > If
> > >       >>>>    no new issues are raised, it is expected that
> > > the draft could go
> > >       >>>>    to WG LC in November or December.
> > >       >>>>    *4.4 draft-ietf-sipcore-keep*
> > >       >>>>    The draft has just finished WG last call and it
> > > has been moved
> > >       > to
> > >       >>>>    IESG today.
> > >       >>>>    *4.5 draft-ietf-sipcore-199*
> > >       >>>>    This draft has been in IESG for a while and it
> > > has got stuck in
> > >       > a
> > >       >>>>    discussion on what are the conditions when
> > this draft is
> > >       > applicable.
> > >       >>>>    The editor is waiting for the comment from the
> > > AD (Robert
> > >       > Sparks).
> > >       >>>>    *4.6 draft**-ietf-bliss-call-completion*
> > >       >>>>    The draft is now in WG LC which has already
> > > brought up some open
> > >       >>>>    issues. Dale Worley has got a list of open
> > > items and he will
> > >       >>>>    share them with the editor.
> > >       >>>>    *4.7 draft-ietf-mmusic-ice-tcp*
> > >       >>>>    There has been discussion on the 3GPP
> > > requirement for this. Now
> > >       > a
> > >       >>>>    new editor has taken over the editorship of the
> > > draft and the
> > >       >>>>    work is ongoing again.
> > >       >>>>    Also an email comment on the foreseen way
> > > forward was received.
> > >       >>>>    The document authors have indicated there are
> > > currently no known
> > >       >>>>    issues and they have solicited a few reviewers.
> > > The authors
> > >       >>>>    expect to be ready for WGLC after the Beijing
> > > meeting (Nov
> > >       > 2010),
> > >       >>>>    assuming no new issues come up.
> > >       >>>>    *4.8 draft-patel-dispatch-cpc-oli-parameter*
> > >       >>>>    There have been no changes since Maastricht,
> > > where the feedback
> > >       >>>>    was not supportive at all. Informational draft
> > > that would
> > >       >>>>    document historically existing solution was
> > > seen as one possible
> > >       >>>>    way forward. However, Tel-URI parameters
> > would require a
> > >       >>>>    standards track document, so this point needs
> > > to be checked.
> > >       >>>>    AP 18 was assigned to determine the best
> way forward.
> > >       >>>>    *4.9
> draft-bakker-sipping-3gpp-ims-xml-body-handling*
> > >       >>>>    This draft has got a patent issue related with
> > > publication
> > >       > number
> > >       >>>>    US 2009/0119382 A1, Bakker et al. which is
> > > dated May 7^th 2009.
> > >       >>>>    3GPP needs to know whether the draft can
> > > proceed to RFC or not
> > >       >>>>    and take appropriate actions based on that.
> > >       >>>>    *4.10 draft-kaplan-dispatch-session-id*
> > >       >>>>    This is the first candidate document for
> > > SIPSCOTCH. The charter
> > >       >>>>    text has been discussed but the group has not
> > > been chartered
> > >       > yet.
> > >       >>>>    This matter has not progressed recently.
> > >       >>>>    Those interested in the chartering of the WG
> > > should contact the
> > >       >>>>    author of the draft to re-start the charter
> > discussion.
> > >       >>>>    *4.11 draft-dawes-dispatch-mediasec-parameter*
> > >       >>>>    On 3GPP side it is seen that DTLS-based
> > > solution is not seen to
> > >       >>>>    work in 3GPP environment, so another solution
> > > is needed. The
> > >       >>>>    editor has not received much feedback on the
> > > DISPATCH mailing
> > >       >>>>    list on his draft. The editor will re-post the
> > > draft to the list
> > >       >>>>    and those driving this work can then give their
> > > comments.
> > >       >>>>    *5. REVIEW OF 3GPP**- IETF DEPENDENCY DOCUMENT*
> > >       >>>>    *5.1 De**pendency document review during the
> > > teleconference*
> > >       >>>>    New version of
> > > draft-liess-dispatch-alert-info-urns has been
> > >       >>>>    distributed today.
> > >       >>>>    The author of
> > > draft-jesske-dispatch-reason-in-responses would
> > >       >>>>    need AD feedback from Gonzalo on how to proceed
> > > with the work.
> > >       >>>>    draft-ietf-simple-msrp-acm is waiting for AD
> > > go-ahead (Gonzalo
> > >       >>>>    Camarillo). So far this draft has been
> > > processed in sync with
> > >       >>>>    draft-ietf-simple-msrp-sessmatch, but it is
> > > being considered
> > >       >>>>    whether that linkage should be broken.
> > >       >>>>    The session matching draft
> > > (draft-ietf-simple-msrp-sessmatch)
> > >       > has
> > >       >>>>    proven controversial both in earlier IETF
> > > discussions and in the
> > >       >>>>    IETF last call. It has now been sent back to WG
> > > to get consensus
> > >       >>>>    on how to proceed. This draft may require
> substantial
> > >       > re-thinking
> > >       >>>>    before it can proceed.
> > >       >>>>    The status of draft-yu-tel-dai in the I-D
> > > tracker will be
> > >       > checked
> > >       >>>>    by Robert Sparks together with Gonzalo Camarillo.
> > >       >>>>    Hannu volunteered to check the latest news on
> > >       >>>>    draft-das-mipshop-andsf-dhcp-options from
> Jari Arkko.
> > >       >>>>    draft-pkix-cmp-transport-protocols is also
> > > marked as critical,
> > >       >>>>    but no comments were made on it.
> > >       >>>>    Email comments were received on the
> following drafts.
> > >       >>>>    draft-mipshop-andsf-dhcp-options is in IESG
> > > evaluation with two
> > >       >>>>    discussions remaining. This is seen to require
> > > a straightforward
> > >       >>>>    update of the draft and the a review by Tim Polk.
> > >       >>>>    draft-ietf-mext-rfc3775bis is in AD review.
> > >       >>>>    draft-ietf-mext-nemo-pd is pending for author's
> > > changes since
> > >       >>>>    September. The discusses seem reasonable.
> > >       >>>>    *6. NEXT MEETING*
> > >       >>>>    Hannu will attend IETF #79 which makes a good
> > > opportunity for
> > >       > the
> > >       >>>>    next status check-up.
> > >       >>>>    *7. ANY OTHER BUSINESS*
> > >       >>>>    None.
> > >       >>>>    *8. CLOSING*
> > >       >>>>    The meeting was closed at 16:20 UTC.
> > >       >>>>    BR,
> > >       >>>>    Hannu Hietalahti
> > >       >>>>    3GPP TSG CT Chairman
> > >       >>>>    tel: +358 40 5021724
> > >       >>>>    <ATT00001..c>
> > >       >>>
> > >       >>>
> > >       >>>    _______________________________________________
> > >       >>>    RAI mailing list
> > >       >>>    [email-masked] <mailto:[email-masked]>
> > >       >>>    https://www.ietf.org/mailman/listinfo/rai
> > >       >>>
> > >       >>>
> > >       >>
> > >       >>
> > >       >>
> > >       >> _______________________________________________
> > >       >> RAI mailing list
> > >       >> [email-masked]
> > >       >> https://www.ietf.org/mailman/listinfo/rai
> > >       > _______________________________________________
> > >       > RAI mailing list
> > >       > [email-masked]
> > >       > https://www.ietf.org/mailman/listinfo/rai
> > >
> > >
> > >
> > >
> > >
> >
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 1 Nov 2010 10:28:38 +0100

> Sent: 01 November 2010 08:45
> Ram Mohan R (rmohanr); Ken Rehor (krehor)
> Subject: RE: Session-id in SIPREC [Was RE: [RAI] Minutes of
> 3GPP - IETF telco on the 19th of October]
>
[JRE] This use case does not really illustrate any need for a unique identifier. It shows that the 4 entities involved (Alice, Bob, B2BUA/SRC and SRS) all receive the UID, but what do these entities use the UID for and what would be the consequences of some of the entities not receiving the UID? For example, if Alice and Bob are able to use the UID for later finding and replaying the recording, I guess that would be a good reason.

> 2) Two party call transfer flow of SRC co-located in UA
[JRE] In this case the Update_metadata flow seems to add a second CS under the umbrella of the same UID used for the first CS. So this would provide the SRS with a link between the two CSs. If Alice, Bob or Carol later wants to find and replay the recording, they can use the UID to find the recording of the set of CSs, and presumably can select a particular CS to replay or replay the two in sequence. However, do you really want Carol to find and replay the CS between Alice and Bob, and do you want Bob to find and replay the CS between Alice and Carol? Perhaps that is just an authorization matter - it depends whether knowledge of the UID is considered sufficient authorisation to replay the set of CSs under that UID.

> 3) Three party conference call flow of SRC co-located in UA
[JRE] A similar authorization question. Is Carol's knowledge of the UID sufficient to allow Alice to access the entire CS between Alice and Bob, even that part when Alice was not a party?

> 4) Two party call transfer of SRC co-located in B2BUA
[JRE] Similar questions arise.

So we need to be clear what the UID will be used for and what it will not be used for.

John (as individual)

> Ram Mohan R

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Nov 2010 09:33:50 -0400

ISTM that, at least in part, this is a discussion of *mechanism*.
Its convenient for modeling to just draw boxes with lines between them. 
But when we get down to mechanisms, especially when conveying this 
information incrementally, it will be necessary to use some sort of 
identifier to identify object to which something must be linked.
I expect that every box in the metamodel will need an "id" attribute in 
order to identify it in a database sense.

Of course, if they are all created by the same SRC, then it can just 
assign ids and remember them, and signal them only in the RS, with no 
need for algorithmic correlation back to the CSs.

ISTM the reason we might need something in the CSs is:
- need to correlate metadata from multiple SRCs
- need for CS participants to access the recorded data/metadata

AFAIK neither of those is in scope right now.

	Thanks,
	Paul

On 11/1/2010 5:28 AM, Elwell, John wrote:
>>> usecases related to this unique identifier. Paul&  Ram,
>> Please correct
>>
>>> me in case I'm wrong.
>>>
>>> usecases text and let us discuss in SIPREC through mailing alias&
>>> solution will not work.</Partha>
>>>
>>>> SIPREC perspective, We will add the requirement&  usecase
>> in SIPREC
>>>>>        >>>     [email-masked]<mailto:[email-masked]>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 1 Nov 2010 16:22:34 +0100

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 01 November 2010 13:34
> To: Elwell, John
> Cc: Parthasarathi R (partr); Hadriel Kaplan; Rosen, Brian;
> [email-masked]; Ram Mohan R (rmohanr); Ken Rehor (krehor)
> Subject: Re: Session-id in SIPREC [Was RE: [RAI] Minutes of
[JRE] But none of Partha's examples showed more than one SRC.

> - need for CS participants to access the recorded data/metadata
[JRE] That was the only reason I could read into Partha's examples.

> AFAIK neither of those is in scope right now.
[JRE] Perhaps not, but it is probably useful to try to understand requirements. They might lead to something that is within scope of the preset SIPREC, or they might lead to other work (outside SIPREC or in a re-chartered SIPREC). Initial SIPREC deliverables don't need to be complete (in the sense of fitting every single deployment case), but should at least be sufficient to satisfy a reasonably broad spectrum of deployment scenarios. If a large number of deployment scenarios would require some sort of UID, we should at least identify requirements - they can always be sent to DISPATCH for further consideration if we can't provide solutions within SIPREC.

John

> > [JRE] This use case does not really illustrate any need for
> a unique identifier. It shows that the 4 entities involved
> (Alice, Bob, B2BUA/SRC and SRS) all receive the UID, but what
> do these entities use the UID for and what would be the
> consequences of some of the entities not receiving the UID?
> For example, if Alice and Bob are able to use the UID for
> later finding and replaying the recording, I guess that would
> be a good reason.
> >
> > [JRE] In this case the Update_metadata flow seems to add a
> second CS under the umbrella of the same UID used for the
> first CS. So this would provide the SRS with a link between
> the two CSs. If Alice, Bob or Carol later wants to find and
> replay the recording, they can use the UID to find the
> recording of the set of CSs, and presumably can select a
> particular CS to replay or replay the two in sequence.
> However, do you really want Carol to find and replay the CS
> between Alice and Bob, and do you want Bob to find and replay
> the CS between Alice and Carol? Perhaps that is just an
> authorization matter - it depends whether knowledge of the
> UID is considered sufficient authorisation to replay the set
> of CSs under that UID.
> >
> > [JRE] A similar authorization question. Is Carol's
> knowledge of the UID sufficient to allow Alice to access the
> entire CS between Alice and Bob, even that part when Alice
> was not a party?
> >
> >>>>>        >>>>     -
> draft-bakker-sipping-3gpp-ims-xml-body-handling

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 2 Nov 2010 22:15:18 +0530

John,

Please read inline.

Thank
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, November 01, 2010 2:59 PM
To: Parthasarathi R (partr); Hadriel Kaplan
Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked]; Ram Mohan R

> 1) Two party basic callflow of SRC co-located in B2BUA
[JRE] This use case does not really illustrate any need for a unique
identifier. It shows that the 4 entities involved (Alice, Bob, B2BUA/SRC
and SRS) all receive the UID, but what do these entities use the UID for
and what would be the consequences of some of the entities not receiving
the UID? For example, if Alice and Bob are able to use the UID for later
finding and replaying the recording, I guess that would be a good
reason.

<Partha> The reason for this usecase is to illustrate that Call-id is
not sufficient for UID and also as you mentioned to indicate the
requirement in UA to replay using UID. </Partha>

> 2) Two party call transfer flow of SRC co-located in UA
[JRE] In this case the Update_metadata flow seems to add a second CS
under the umbrella of the same UID used for the first CS. So this would
provide the SRS with a link between the two CSs. If Alice, Bob or Carol
later wants to find and replay the recording, they can use the UID to
find the recording of the set of CSs, and presumably can select a
particular CS to replay or replay the two in sequence.
<Partha> It is the primary motive for this callflow </Partha>
 However, do you really want Carol to find and replay the CS between
Alice and Bob, and do you want Bob to find and replay the CS between
Alice and Carol? Perhaps that is just an authorization matter - it
depends whether knowledge of the UID is considered sufficient
authorisation to replay the set of CSs under that UID.

<Partha> I don't have put much details into authorization for each user.
It is an open issue. We will discuss in detail to understand the
authorization SIPREC requirement to get more clarity. </Partha>

> 3) Three party conference call flow of SRC co-located in UA
[JRE] A similar authorization question. Is Carol's knowledge of the UID
sufficient to allow Alice to access the entire CS between Alice and Bob,
even that part when Alice was not a party?

So we need to be clear what the UID will be used for and what it will
not be used for.

John (as individual)

> between now and Beijing, and if there are issues to discuss, we can 
> bash the agenda to make room.
>
> John
>
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 2 Nov 2010 18:04:10 +0100

Partha,

Are we identifying a requirement to extend the notification to a party that the call is being recorded by including with that notification an identifier that can subsequently be used for retrieving the recording? We don't know whether all parties should receive the same identifier, or whether different parties should be given different identifiers for the same recording.

John (as individual)

> Sent: 02 November 2010 16:45

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 2 Nov 2010 22:39:13 +0530

John/Paul,

In the given usecases, UID is required for two reasons:

1) Need for CS participants to access the recorded data/metadata (All
usecases illustrates this) using UID. Authorization is an open issue as
John pointed out.

2) SRC has to identify that CS are related to the single RS during the
call service like call transfer (REFER based). Usecase 4 illustrate the
change of CS change from Alice-Bob CS to Bob-carol CS and SRC has to
keep track of this change using UID. Without UID, Bob-carol will be
considered as not part of the existing RS. This UID requirement requires
support of UA's involved in SIP recording.

Please read inline for more comments.

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, November 01, 2010 8:53 PM
To: Paul Kyzivat (pkyzivat)
Cc: Parthasarathi R (partr); Hadriel Kaplan; Rosen, Brian;

> Subject: Re: Session-id in SIPREC [Was RE: [RAI] Minutes of 3GPP - 
[JRE] But none of Partha's examples showed more than one SRC.
<Partha> With the current discussion in SIPREC, two SRC for single RS is
outside the scope of SIPREC as of now. In case multiple SRC has to be
correlated, lot of other requirements pops-up including the negotiating
between two SRC if required. </Partha>

[JRE] That was the only reason I could read into Partha's examples.
<partha> It is one of the main motive </Partha>

> AFAIK neither of those is in scope right now.
[JRE] Perhaps not, but it is probably useful to try to understand
requirements. They might lead to something that is within scope of the
preset SIPREC, or they might lead to other work (outside SIPREC or in a
re-chartered SIPREC). Initial SIPREC deliverables don't need to be
complete (in the sense of fitting every single deployment case), but
should at least be sufficient to satisfy a reasonably broad spectrum of
deployment scenarios. If a large number of deployment scenarios would
require some sort of UID, we should at least identify requirements -
they can always be sent to DISPATCH for further consideration if we
can't provide solutions within SIPREC.
<partha> Agreed </Partha>

John

> >> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked]; Ram 
> >> Mohan R (rmohanr); Ken Rehor (krehor)
> a unique identifier. It shows that the 4 entities involved (Alice, 
> Bob, B2BUA/SRC and SRS) all receive the UID, but what do these 
> entities use the UID for and what would be the consequences of some of

> the entities not receiving the UID?
> For example, if Alice and Bob are able to use the UID for later 
> second CS under the umbrella of the same UID used for the first CS. So

> this would provide the SRS with a link between the two CSs. If Alice, 
> Bob or Carol later wants to find and replay the recording, they can 
> use the UID to find the recording of the set of CSs, and presumably 
> can select a particular CS to replay or replay the two in sequence.
> knowledge of the UID sufficient to allow Alice to access the entire CS

> between Alice and Bob, even that part when Alice was not a party?
> >
> >> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked]; Ram 
> >> Mohan R (rmohanr); Ken Rehor (krehor)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 2 Nov 2010 22:49:29 +0530

John,

I remember the requirement to notify all participants in the recording
session to be notified about the recording using some special tone or
announcement. One of the purpose of unique identifier is to replay by
the participants. 

I guess that you are looking for different identifier to differentiate
the users for better authorization mechanism in retrieval? 

Thanks
Partha
-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, November 02, 2010 10:34 PM
To: Parthasarathi R (partr); Hadriel Kaplan
Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked]; Ram Mohan R

Partha,

Are we identifying a requirement to extend the notification to a party
that the call is being recorded by including with that notification an
identifier that can subsequently be used for retrieving the recording?
We don't know whether all parties should receive the same identifier, or
whether different parties should be given different identifiers for the
same recording.

John (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Nov 2010 14:05:14 -0400

I'll join with John on this question. I don't know of any requirement to 
inform CS participants of *how* to access the recording. In most use 
cases that I am aware of, the participants are not provided with 
permission nor any mechanism to access the recording.

Information that you are being recorded is more of a warning to be 
careful what you say than it is an invitation to listen.

	Thanks,
	Paul

On 11/2/2010 1:04 PM, Elwell, John wrote:
>> requirement in UA to replay using UID.</Partha>
>>
>> <Partha>  It is the primary motive for this callflow</Partha>
>> authorization SIPREC requirement to get more clarity.</Partha>
>>

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 3 Nov 2010 01:04:20 +0530

Conference call recording is a use-case where participants are typically
provided a URL of the recording at the end of the call, but outside of
the CS. The same can hold good for a 2-party call as well. However, if A
transfers B to C, it is typically a new recording session, and B and C
get a new URL at the end of their conversion. Tying all conversations
together and conveying a unique ID within the CSs looks interesting, but
doesn't seem a compelling requirement.

Muthu 

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of
|Paul Kyzivat (pkyzivat)
|Sent: Tuesday, November 02, 2010 11:35 PM
|To: Elwell, John
|Cc: Hadriel Kaplan; [email-masked]; Rosen,Brian
|Subject: Re: [siprec] Session-id in SIPREC [Was RE: [RAI] Minutes of
3GPP -
|IETF telco on the 19th of October]
|
|I'll join with John on this question. I don't know of any requirement
to
|inform CS participants of *how* to access the recording. In most use
|cases that I am aware of, the participants are not provided with
|permission nor any mechanism to access the recording.
|
|Information that you are being recorded is more of a warning to be
|careful what you say than it is an invitation to listen.
|
|	Thanks,
|	Paul
|
|On 11/2/2010 1:04 PM, Elwell, John wrote:
|> Partha,
|>
|> Are we identifying a requirement to extend the notification to a
party
|that the call is being recorded by including with that notification an
|identifier that can subsequently be used for retrieving the recording?
We
|don't know whether all parties should receive the same identifier, or
|whether different parties should be given different identifiers for the
same
|recording.
|>
|> John (as individual)
|>
|>> -----Original Message-----
|>> From: Parthasarathi R (partr) [mailto:[email-masked]]
|>> Sent: 02 November 2010 16:45
|>> To: Elwell, John; Hadriel Kaplan
|>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked];
|>> Ram Mohan R (rmohanr); Ken Rehor (krehor)
|>> Subject: RE: Session-id in SIPREC [Was RE: [RAI] Minutes of
|>> 3GPP - IETF telco on the 19th of October]
|>>
|>> John,
|>>
|>> Please read inline.
|>>
|>> Thank
|>> Partha
|>>
|>> -----Original Message-----
|>> From: Elwell, John [mailto:[email-masked]]
|>> Sent: Monday, November 01, 2010 2:59 PM
|>> To: Parthasarathi R (partr); Hadriel Kaplan
|>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked];
|>> Ram Mohan R
|>> (rmohanr); Ken Rehor (krehor)
|>> Subject: RE: Session-id in SIPREC [Was RE: [RAI] Minutes of
|>> 3GPP - IETF
|>> telco on the 19th of October]
|>>
|>>
|>>
|>>> -----Original Message-----
|>>> From: Parthasarathi R (partr) [mailto:[email-masked]]
|>>> Sent: 01 November 2010 08:45
|>>> To: Elwell, John; Hadriel Kaplan
|>>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked];
|>> Ram Mohan
|>>> R (rmohanr); Ken Rehor (krehor)
|>>> Subject: RE: Session-id in SIPREC [Was RE: [RAI] Minutes of 3GPP -
|>>> IETF telco on the 19th of October]
|>>>
|>>> As the starting time for the discussion, I attached 4 usecase and
|>>> requirement for SIPREC unique identifier. The usecases are
|>>>
|>>> 1) Two party basic callflow of SRC co-located in B2BUA
|>> [JRE] This use case does not really illustrate any need for a unique
|>> identifier. It shows that the 4 entities involved (Alice,
|>> Bob, B2BUA/SRC
|>> and SRS) all receive the UID, but what do these entities use
|>> the UID for
|>> and what would be the consequences of some of the entities
|>> not receiving
|>> the UID? For example, if Alice and Bob are able to use the
|>> UID for later
|>> finding and replaying the recording, I guess that would be a good
|>> reason.
|>>
|>> <Partha>  The reason for this usecase is to illustrate that Call-id
is
|>> not sufficient for UID and also as you mentioned to indicate the
|>> requirement in UA to replay using UID.</Partha>
|>>
|>>> 2) Two party call transfer flow of SRC co-located in UA
|>> [JRE] In this case the Update_metadata flow seems to add a second CS
|>> under the umbrella of the same UID used for the first CS. So
|>> this would
|>> provide the SRS with a link between the two CSs. If Alice,
|>> Bob or Carol
|>> later wants to find and replay the recording, they can use the UID
to
|>> find the recording of the set of CSs, and presumably can select a
|>> particular CS to replay or replay the two in sequence.
|>> <Partha>  It is the primary motive for this callflow</Partha>
|>>   However, do you really want Carol to find and replay the CS
between
|>> Alice and Bob, and do you want Bob to find and replay the CS between
|>> Alice and Carol? Perhaps that is just an authorization matter - it
|>> depends whether knowledge of the UID is considered sufficient
|>> authorisation to replay the set of CSs under that UID.
|>>
|>> <Partha>  I don't have put much details into authorization for
|>> each user.
|>> It is an open issue. We will discuss in detail to understand the
|>> authorization SIPREC requirement to get more clarity.</Partha>
|>>
|>>> 3) Three party conference call flow of SRC co-located in UA
|>> [JRE] A similar authorization question. Is Carol's knowledge
|>> of the UID
|>> sufficient to allow Alice to access the entire CS between
|>> Alice and Bob,
|>> even that part when Alice was not a party?
|>>
|>>> 4) Two party call transfer of SRC co-located in B2BUA
|>> [JRE] Similar questions arise.
|>>
|>> So we need to be clear what the UID will be used for and what it
will
|>> not be used for.
|>>
|>> John (as individual)
|>>
|>>
|>>>
|>>> Please provide your valuable comments on the document. I'll
|>> update the
|>>
|>>> document based on the discussion in the e-mail thread.
|>>>
|>>> Thanks
|>>> Partha
|>>>
|>>> -----Original Message-----
|>>> From: Elwell, John [mailto:[email-masked]]
|>>> Sent: Thursday, October 28, 2010 6:59 PM
|>>> To: Parthasarathi R (partr); Hadriel Kaplan
|>>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked];
|>> Ram Mohan
|>>> R (rmohanr); Ken Rehor (krehor)
|>>> Subject: RE: Session-id in SIPREC [Was RE: [RAI] Minutes of 3GPP -
|>>> IETF telco on the 19th of October]
|>>>
|>>> Partha,
|>>>
|>>> Thanks for offering to work on this. If there has been good
|>> discussion
|>>
|>>> between now and Beijing, and if there are issues to discuss, we can
|>>> bash the agenda to make room.
|>>>
|>>> John
|>>>
|>>>
|>>>> -----Original Message-----
|>>>> From: Parthasarathi R (partr) [mailto:[email-masked]]
|>>>> Sent: 28 October 2010 12:36
|>>>> To: Elwell, John; Hadriel Kaplan
|>>>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked];
|>>> Ram Mohan
|>>>> R (rmohanr); Ken Rehor (krehor)
|>>>> Subject: RE: Session-id in SIPREC [Was RE: [RAI] Minutes
|>> of 3GPP -
|>>>> IETF telco on the 19th of October]
|>>>>
|>>>> John,
|>>>>
|>>>> I'm of the same opinion that unique identifier mechanism will be
|>>>> outside the scope of SIPREC.
|>>>>
|>>>> ram-siprec-metadata model indicates the unique identifier
|>> as an one
|>>>> parameter in CS or CS group. Till now, metadata model is based on
|>>>> usecase and requirement in siprec-req. IMO, It will not provides
|>>>> usecases related to this unique identifier. Paul&  Ram,
|>>> Please correct
|>>>
|>>>> me in case I'm wrong.
|>>>>
|>>>> I had request lot of times for usecase document for the session
|>>>> id/SIPSCOTCH in Dispatch and send couple of usecase
|>> related to the
|>>>> same.
|>>>> Most of the usecases are related to SIPREC as well. I'll
|>>> come up with
|>>>> usecases text and let us discuss in SIPREC through
|>> mailing alias&
|>>>> during IETF-79 meeting. Based on the discussion, Let us
|>>> decide whether
|>>>
|>>>> it is required to have separate draft or adding it in any
|>>> one of the
|>>>> existing SIPREC draft. Please let me know your opinion on
|>> the same.
|>>>>
|>>>> Please read inline for more comments
|>>>>
|>>>> Thanks
|>>>> Partha
|>>>>
|>>>> -----Original Message-----
|>>>> From: Elwell, John [mailto:[email-masked]]
|>>>> Sent: Thursday, October 28, 2010 3:42 PM
|>>>> To: Parthasarathi R (partr); Hadriel Kaplan
|>>>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked];
|>>> Ram Mohan
|>>>> R (rmohanr); Ken Rehor (krehor)
|>>>> Subject: RE: Session-id in SIPREC [Was RE: [RAI] Minutes
|>> of 3GPP -
|>>>> IETF telco on the 19th of October]
|>>>>
|>>>> Partha,
|>>>>
|>>>> Hadriel's SIPSCOTCH proposal address the problem of a single
|>>>> identifier for the same call on both sides of a B2BUA such
|>>> as an SBC.
|>>>> I get the impression that what De Villiers is asking for is
|>>> a means of
|>>>
|>>>> tying together two calls that are somehow linked, e.g.,
|>> one arising
|>>>> from the transfer of the other. The two calls would
|>>> typically involve
|>>>> the same remote party (a customer say), but the requirements are
|>>>> subtly different, e.g., tying together two calls on the
|>>> same side of
|>>>> an SBC, as opposed to tying together two halves of a call passing
|>>>> through an SBC.
|>>>> It could be that the same solution will work for both (although I
|>>>> understand Hadriel's concerns, I think), but we have not really
|>>>> documented the problem in detail. For example, if agent A makes a
|>>>> consultation call to agent B, should that also have the
|>>> same ID as the
|>>>
|>>>> original call and/or the call that eventually results
|>> from transfer?
|>>>>
|>>>> <Partha>  This is one of the 3PCC usecase where the current
|>>> session-id
|>>>> solution will not work.</Partha>
|>>>>
|>>>> So in my opinion we need more - whether that can go straight into
|>>>> siprec-req, whether it needs to go into ram-siprec-metadata, or
|>>>> whether it merits its own draft, I am not sure. However, it
|>>> is quite
|>>>> likely that it would require a mechanism that would be
|>> outside the
|>>>> scope of SIPREC to specify, and hence having problem
|>> statement and
|>>>> requirements in a separate draft might be helpful.
|>>>>
|>>>> John
|>>>>
|>>>>> -----Original Message-----
|>>>>> From: Parthasarathi R (partr) [mailto:[email-masked]]
|>>>>> Sent: 28 October 2010 09:59
|>>>>> To: Elwell, John; Hadriel Kaplan
|>>>>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [email-masked];
|>>>> Ram Mohan
|>>>>> R (rmohanr); Ken Rehor (krehor)
|>>>>> Subject: Session-id in SIPREC [Was RE: [RAI] Minutes of 3GPP
|>>>>> - IETF telco on the 19th of October]
|>>>>>
|>>>>>
|>>>>> John,
|>>>>>
|>>>>> As discussed in the attached mail thread, B2BUA acts as
|>>> SRC and SRC
|>>>>> has to inform the set of  communication session using an unique
|>>>>> identifier, it can't be call-id and the proposal is to use
|>>>> session-id.
|>>>>
|>>>>> In case you feel that the requirement and usecase is not
|>>> clear from
|>>>>> SIPREC perspective, We will add the requirement&  usecase
|>>> in SIPREC
|>>>>> requirement document itself. Please clarify whether
|>>> separate ID is
|>>>>> required for this unique recording id requirement?
|>>>>>
|>>>>> I like to hear from you whether two SRC for the single
|>>> communication
|>>>>> session(CS) is outside the scope of SIPREC or not. Because,
|>>>> Recording
|>>>>> session group in metadata model is removed  from metadata
|>>>> draft that
|>>>>> two SRC for single CS is outside the scope of SIPREC.
|>>>>>
|>>>>> Thanks
|>>>>> Partha
|>>>>>
|>>>>> -----Original Message-----
|>>>>> From: Elwell, John [mailto:[email-masked]]
|>>>>> Sent: Thursday, October 28, 2010 1:22 PM
|>>>>> To: Parthasarathi R (partr); Hadriel Kaplan
|>>>>> Cc: Paul Kyzivat (pkyzivat); [email-masked]; Rosen, Brian
|>>>>> Subject: RE: [RAI] Minutes of 3GPP - IETF telco on the 19th
|>>>> of October
|>>>>>
|>>>>> Partha,
|>>>>>
|>>>>> First, as an individual, I am quite keen to see Hadriel's draft
|>>>>> progress, even if its scope is limited to troubleshooting.
|>>>>>
|>>>>> Second, as SIPREC chair, it is unclear to me that we have
|>>>> in SIPREC a
|>>>>> clear problem statement. For example, one form of the
|>>>> problem that I
|>>>>> could imagine is that two session recording clients (one
|>>>> located at a
|>>>>> first agent, say, and the other located at a second agent,
|>>>> say) both
|>>>>> generate recording sessions to a session recording server
|>>> to record
|>>>>> what are two separate communication sessions from the
|>>>> perspective of
|>>>>> the two clients. However, the communication sessions are
|>>>> linked (i.e.,
|>>>>
|>>>>> part of the same thread) - perhaps the second session
|>>> resulted from
|>>>>> transfer of the first session from the first agent to
|>> the second
|>>>>> agent.
|>>>>> Some form of
|>>>>> ID is needed to correlate the two recordings when they
|>> reach the
|>>>>> session recording server. This is one possible form of the
|>>>> problem -
|>>>>> it may or may not be a valid problem and it may or may
|>> not be the
|>>>>> total problem concerning session IDs and SIPREC.
|>>>>>
|>>>>> I would like to see discussion of the problem statement on
|>>>> the SIPREC
|>>>>> mailing list, and ideally I would like to see an I-D on the
|>>>> subject (I
|>>>>
|>>>>> think we need more than what we have in siprec-req). If
|>> we have a
|>>>>> clear problem statement and requirements, then we can
|>> attempt to
|>>>>> address the problem either in SIPREC or elsewhere in RAI, as
|>>>>> appropriate. In my opinion it is too early to say whether
|>>> Hadriel's
|>>>>> draft fulfils a SIPREC need.
|>>>>>
|>>>>> John
|>>>>>
|>>>>>> -----Original Message-----
|>>>>>> From: Parthasarathi R (partr) [mailto:[email-masked]]
|>>>>>> Sent: 28 October 2010 07:21
|>>>>>> To: Hadriel Kaplan
|>>>>>> Cc: Paul Kyzivat (pkyzivat); [email-masked]; Elwell, John
|>>>>>> Subject: RE: [RAI] Minutes of 3GPP - IETF telco on the 19th
|>>>>> of October
|>>>>>>
|>>>>>> Hadriel,
|>>>>>>
|>>>>>> I'm reading your mail like IETF has to add "n" number of
|>>>>> correlation
|>>>>>> id header based upon the usage.  we need to create the
|>>>>> correlation id
|>>>>>> like troubleshoot-id: xxxxx,
|>>>>>> recording-cs-id: xxxxxx individually. In case everybody
|>>>>> feels so, I'm
|>>>>>> fine with the approach.
|>>>>>>
|>>>>>> Still, I'm not getting your concern w.r.t SIPREC
|>>>> correlation id and
|>>>>>> why SIPREC session id will not be passed across in SIP
|>>>> devices but
|>>>>>> trouble-shoot-id will? Please elaborate in this mail
|>>> thread or in
|>>>>>> SIPREC IETF alias.
|>>>>>>
|>>>>>> In my experience with unique SIP session identification
|>>>>> (cisco-guid),
|>>>>>> the current proposed "session-id" will not work for
|>>>> number of 3PCC
|>>>>>> callflows. In case you feel that troubleshoot id for 3PCC
|>>>>> callflow has
|>>>>>
|>>>>>> to be based on another
|>>>>>> troubleshoot-id-part-2 ;-) Then it requires more
|>>>> discussion in IETF.
|>>>>>>
|>>>>>> Thanks
|>>>>>> Partha
|>>>>>>
|>>>>>>
|>>>>>> ________________________________
|>>>>>>
|>>>>>> From: Hadriel Kaplan [mailto:[email-masked]]
|>>>>>> Sent: Thursday, October 28, 2010 10:52 AM
|>>>>>> To: Parthasarathi R (partr)
|>>>>>> Cc: Paul Kyzivat (pkyzivat); [email-masked];
|>>>>>> [email-masked]
|>>>>>> Subject: Re: [RAI] Minutes of 3GPP - IETF telco on the 19th
|>>>>> of October
|>>>>>>
|>>>>>>
|>>>>>>
|>>>>>> If you don't want to implement support for passing through a
|>>>>>> session-id header, then don't.  No one's making you.
|>>>> We're talking
|>>>>>> about an RFC, not a Biblical commandment.  There are a
|>>>> boat-load of
|>>>>>> RFC's no one's ever implemented.
|>>>>>>
|>>>>>> It's not the be-all-end-all final solution for world hunger.
|>>>>>> It's just one header.  It's one tool in a bag of tools.
|>>>>>>
|>>>>>> If some vendors support passing a session-id header and
|>>>>> other's don't,
|>>>>>
|>>>>>> it won't be as useful as it could have been.
|>>>>>> My customers tell me such a header would help them.  Maybe
|>>>>> I'm naive,
|>>>>>> but I would think when customers tell their vendors to do
|>>>>> something,
|>>>>>> the vendors generally try to do it.
|>>>>>> Especially if it's trivial to implement and helps the vendors
|>>>>>> *themselves* with supporting the customers in TAC.  So my
|>>>> belief is
|>>>>>> the market will decide if session-id succeeds - customers
|>>>>> will either
|>>>>>> want it, or not.  Meanwhile, all it takes to find out is to
|>>>>> publish a
|>>>>>> fairly simple RFC.  If it fails, we've wasted some IETF
|>>>>> people's time
|>>>>>> and an RFC number.  If it succeeds, we've made SIP a little
|>>>>> bit easier
|>>>>>
|>>>>>> to manage, for all of us.
|>>>>>>
|>>>>>> SIPCLF is orthogonal to session-id, really. In fact, one
|>>>> would hope
|>>>>>> the session-id would be recorded in SIPCLF as well.  Had we
|>>>>> published
|>>>>>> session-id when it was initially proposed, it would have been
|>>>>>> available in time for SIPCLF to make a mandatory field.
|>>>>>>
|>>>>>> As for SIPREC, that's exactly the problem: I already *know*
|>>>>> of cases
|>>>>>> where we'll need to remove whatever correlation id
|>>> siprec ends up
|>>>>>> using.  Overloading this header for such things is just
|>>> bound to
|>>>>>> reduce its troubleshooting value, because we'll need to
|>>> remove or
|>>>>>> change it.  But that's *OK* - we have no shortage of
|>>> header names
|>>>>>> available in SIP ABNF.
|>>>>>> They can go define whatever new header-name they'd like,
|>>>>> with another
|>>>>>> value.
|>>>>>>
|>>>>>> -hadriel
|>>>>>>
|>>>>>> On Oct 27, 2010, at 11:30 PM, Parthasarathi R (partr) wrote:
|>>>>>>
|>>>>>>
|>>>>>>                        Hadriel,
|>>>>>>                SBC removing the header in the incoming SIP
|>>>>> message and
|>>>>>> forming the new outgoing message is the default behavior
|>>>> and it is
|>>>>>> nothing to do with session-id proposal.
|>>>>>> Session-id IETF RFC will help SBC to design for passing
|>>>> across the
|>>>>>> specific header in the forthcoming release. Which
|>>>>> forthcoming release
|>>>>>> (after 3 years or 10 years) depends upon the compelling
|>>>> reason for
|>>>>>> this header in specific SBC or other SIP device as we have
|>>>>> number of
|>>>>>> SIP RFC today to implement.
|>>>>>>                AFAIK, most of the companies create their
|>>>> own unique
|>>>>>> session id to identify the session and using it within
|>>>>> their network
|>>>>>> for different purposes. Standardizing session id SIP header
|>>>>> makes all
|>>>>>> the companies to interop in case the purpose of the
|>>>>> specific company's
|>>>>>
|>>>>>> unique session id is not broken. IMO, troubleshooting is
|>>>> one of the
|>>>>>> usecase which has workaround by building the
|>>> appropriate logging
|>>>>>> mechanism and tools to analyze the log across the device. I
|>>>>> guess that
|>>>>>
|>>>>>> SIPCLF WG addresses this requirement. If troubleshooting is
|>>>>> the only
|>>>>>> scope of the session-id, the adaptability of this header
|>>>> will take
|>>>>>> long time or may not take place in case the company
|>>>> provides better
|>>>>>> means for troubleshooting.
|>>>>>>                In case of SIPREC, the multiple
|>>>> communication session
|>>>>>> has to be related together in a single recording session
|>>>> using the
|>>>>>> unique id. Most of the folks in SIPREC mailing alias
|>>> thinks that
|>>>>>> session-id in communication session will serve the purpose.
|>>>>> IMO, the
|>>>>>> usability of the session-id has to be extended and it
|>> has to be
|>>>>>> generic rather than specific service or application.
|>>>>>>                As I mentioned in the earlier mail thread
|>>>>> with RE-INVITE
|>>>>>
|>>>>>> based transfer in B2BUA usecase, session-id in the current
|>>>>> form will
|>>>>>> not serve the purpose for troubleshooting as well.
|>>> Cisco has the
|>>>>>> header similar to session-id which is named as "cisco-guid"
|>>>>> which has
|>>>>>> the issue in handling the mentioned usecase. We need to
|>>> find the
|>>>>>> better solution for session-id.
|>>>>>>                Thanks
|>>>>>>        Partha
|>>>>>>
|>>>>>>
|>>>>>>
|>>>>>>
|>>>>>> ________________________________
|>>>>>>
|>>>>>>        From: Hadriel Kaplan [mailto:[email-masked]]
|>>>>>>        Sent: Wed 10/27/2010 7:35 PM
|>>>>>>        To: Parthasarathi R (partr)
|>>>>>>        Cc: Paul Kyzivat (pkyzivat); [email-masked]
|>>>>>>        Subject: Re: [RAI] Minutes of 3GPP - IETF telco on
|>>>>> the 19th of
|>>>>>> October
|>>>>>>
|>>>>>>
|>>>>>>
|>>>>>>
|>>>>>>        I'm not sure which way you mean this - do you mean
|>>>> if I don't
|>>>>>> get this published as an IETF RFC then SBC's will remove
|>>>>> it, or do you
|>>>>>
|>>>>>> mean even if we go define this as an IETF RFC SBC's will
|>>>>> still remove
|>>>>>> it?
|>>>>>>
|>>>>>>        I'm fairly confident that if it's published as an
|>>>> IETF RFC in
|>>>>>> its current form then SBC's won't remove it - or they
|>>>> will provide
|>>>>>> upgrades to not remove it.  I believe that because in my
|>>>> experience
|>>>>>> SBC's do what their owners/operators want them to do.
|>>   Whether
|>>>>>> specific operators/admins decide to have their SBCs remove
|>>>>> it or not
|>>>>>> remains to be seen, but if it's useful for troubleshooting
|>>>>> while not
|>>>>>> harmful then my guess is they'll want the session-id to
|>>> be passed
|>>>>>> through.
|>>>>>> IF it causes any call failures, then they'll block it,
|>>>> which is why
|>>>>>> I'm so concerned about expanding the scope of it to other
|>>>>> things than
|>>>>>> troubleshooting.
|>>>>>>
|>>>>>>        If it's not published as an IETF RFC, then its less
|>>>> likely to
|>>>>>> succeed in the marketplace.  I could just take it to 3gpp,
|>>>>> but I was
|>>>>>> hoping to make this useful in non-IMS networks as
|>> well, such as
|>>>>>> Enterprise.
|>>>>>>
|>>>>>>        -hadriel
|>>>>>>
|>>>>>>
|>>>>>>        On Oct 27, 2010, at 5:50 AM, Parthasarathi R
|>>> (partr) wrote:
|>>>>>>
|>>>>>>        >  Hadriel,
|>>>>>>        >
|>>>>>>        >  In terms of SIP SBC, any unique ID or header or
|>>>>> body will be
|>>>>>> removed or
|>>>>>>        >  modified whether it is for troubleshooting or for
|>>>> any other
|>>>>>> application
|>>>>>>        >  purpose.
|>>>>>>        >
|>>>>>>        >  Let us take the troubleshooting application itself.
|>>>>>> What is the
|>>>>>>        >  requirement for Enterprise SBC to pass the
|>>>>> troubleshooting-id
|>>>>>> to service
|>>>>>>        >  provider network in case SBC acts as UA or IMS UE
|>>>>> to service
|>>>>>> provider
|>>>>>>        >  network? Being the border element, SBC may wish to
|>>>>> put the new
|>>>>>>        >  troubleshooting id (hiding session-id) to the
|>>>>> outgoing dialog
|>>>>>> for the
|>>>>>>        >  same session rather than passing the existing
|>>>>> troubleshooting
|>>>>>> id.
|>>>>>>        >
|>>>>>>        >  I agree that the unique identification for the
|>>> session is
|>>>>>> required in
|>>>>>>        >  different SIP application for different requirements.
|>>>>>> I'm seeing lot of
|>>>>>>        >  requirement in Enterprise deployment other than
|>>>>>> troubleshooting and
|>>>>>>        >  also, noticed the unique-id requirement in SIPREC
|>>>>> to identify
|>>>>>> the group
|>>>>>>        >  of communication session.
|>>>>>>        >
|>>>>>>        >  Until otherwise SBC or any other middle box
|>>>>>> (B2BUA/Focus) decides to
|>>>>>>        >  pass the specific header(s) based on standard, this
|>>>>> unique-id
|>>>>>> approach
|>>>>>>        >  will never fly.
|>>>>>>        >
|>>>>>>        >  Thanks
|>>>>>>        >  Partha
|>>>>>>        >
|>>>>>>        >  -----Original Message-----
|>>>>>>        >  From: [email-masked]
|>>> [mailto:[email-masked]]
|>>>>>> On Behalf Of
|>>>>>>        >  Paul Kyzivat (pkyzivat)
|>>>>>>        >  Sent: Tuesday, October 26, 2010 9:44 PM
|>>>>>>        >  To: [email-masked]
|>>>>>>        >  Subject: Re: [RAI] Minutes of 3GPP - IETF telco on
|>>>>> the 19th of
|>>>>>
|>>>>>> October
|>>>>>>        >
|>>>>>>        >  ISTM there is a Catch-22 here.
|>>>>>>        >
|>>>>>>        >  If an ID is potentially of use for more than one
|>>>>> purpose, some
|>>>>>
|>>>>>> middlebox
|>>>>>>        >  wants to mess with it in regard to one of those
|>>> purposes.
|>>>>>> (Block it,
|>>>>>>        >  make it work "better", etc.) Hence the only
|>>>> solution is to
|>>>>>> create a
|>>>>>>        >  separate ID for each and every possible use. :-(
|>>>>>>        >
|>>>>>>        >         Thanks,
|>>>>>>        >         Paul
|>>>>>>        >
|>>>>>>        >  On 10/26/2010 11:39 AM, Hadriel Kaplan wrote:
|>>>>>>        >>
|>>>>>>        >>  The problem with using session-id for anything else
|>>>>>> is: for every
|>>>>>>        >>  other use-case discussed so far, I can
|>> easily imagine
|>>>>>> situations where
|>>>>>>        >
|>>>>>>        >>  a middlebox would need to change the
|>>> session-id to make
|>>>>>> things work,
|>>>>>>        >>  thereby negating its troubleshooting value.
|>>>>>>        >>
|>>>>>>        >>  -hadriel
|>>>>>>        >>
|>>>>>>        >>  On Oct 26, 2010, at 10:59 AM, Peter Musgrave wrote:
|>>>>>>        >>
|>>>>>>        >>>  Hi Hadriel,
|>>>>>>        >>>
|>>>>>>        >>>  I have implemented this as well. It has
|>> utility in a
|>>>>>> non-trouble
|>>>>>>        >>>  shooting context in my application.
|>>>>>>        >>>
|>>>>>>        >>>  I think the issue in IETF was that we fell into
|>>>>> the "solve
|>>>>>> world
|>>>>>>        >>>  hunger" trap. SIPREC through they might find it
|>>>>> useful for
|>>>>>> session
|>>>>>>        >>>  correlation but in a pure SIP sense this
|>>>>> mechanism does not
|>>>>>> guarantee
|>>>>>>        >
|>>>>>>        >>>  dialog correlation...
|>>>>>>        >>>
|>>>>>>        >>>  Peter Musgrave
|>>>>>>        >>>
|>>>>>>        >>>  On Tue, Oct 26, 2010 at 10:38 AM, Hadriel Kaplan
|>>>>>>        >>>  <[email-masked]
|>>>>>> <mailto:[email-masked]>>  wrote:
|>>>>>>        >>>
|>>>>>>        >>>
|>>>>>>        >>>     Hi,
|>>>>>>        >>>     I see the topic of session-id and SIPSCOTCH came
|>>>>>> up in this
|>>>>>>        >>>     meeting. I've tried getting it chartered, but it
|>>>>>> appears there
|>>>>>>        >>>     isn't consensus that the narrow topic I want
|>>>>> to focus on
|>>>>>>        >>>     (troubleshooting) is what other people
|>> care about.
|>>>>>>        >>>     (well... not for people in the IETF anyway - I
|>>>>>> get constant
|>>>>>>        >>>     queries about this draft mechanism from service
|>>>>>> providers, but
|>>>>>>        >>>     they don't generally join nor comment in IETF
|>>>>>> mailing lists)
|>>>>>>        >>>
|>>>>>>        >>>     So I don't really know what to do, other than
|>>>>>> just implement it
|>>>>>>        >>>     and convince some other vendors to as well, and
|>>>>>> avoid the IETF.
|>>>>>>        >>>     The IETF just isn't a good place for dealing
|>>>>>> with operational
|>>>>>>        >>>     issues in SIP, afaict.
|>>>>>>        >>>
|>>>>>>        >>>     -hadriel
|>>>>>>        >>>
|>>>>>>        >>>
|>>>>>>        >>>     On Oct 22, 2010, at 9:32 AM,
|>>>>> <[email-masked]
|>>>>>>        >>>     <mailto:[email-masked]>>
|>>>>>> <[email-masked]
|>>>>>>        >>>     <mailto:[email-masked]>>  wrote:
|>>>>>>        >>>
|>>>>>>        >>>>     Dear all,
|>>>>>>        >>>>     please find the minutes of the 3GPP - IETF
|>>>>>> telco earlier this
|>>>>>>        >  week.
|>>>>>>        >>>>     *Date:*19^th October 2010
|>>>>>>        >>>>     *Time:*15:00 - 17:00 UTC
|>>>>>>        >>>>     *Venue:*Phone conference
|>>>>>>        >>>>     *Participants:*
|>>>>>>        >>>>     Hannu Hietalahti (notetaker), Atle Monrad,
|>>>>>> Peter Schmitt,
|>>>>>>        >>>>     Christer Holmberg, Peter Dawes, Bengt Sahlin,
|>>>>>> Keith Drage, Milan
|>>>>>>        >>>>     Patel, Georg Mayer,
|>>>>>>        >>>>     Robert Sparks, Adam Roach, Dale Worley, Spencer
|>>>>>> Dawkins, Dan
|>>>>>>        >>>>     Romascanu, Jari Arkko, Paul Kyzivat,
|>> Ben Campbell
|>>>>>>        >>>>     *Agenda:*
|>>>>>>        >>>>     -------------
|>>>>>>        >>>>     1. Roll call
|>>>>>>        >>>>     2. Review of action points
|>>>>>>        >>>>     3. ATOCA work
|>>>>>>        >>>>     - Presentation of 3GPP PWS in IETF #79
|>>>>>>        >>>>     4. Stalled drafts
|>>>>>>        >>>>     - draft-drage-sipping-rfc3455bis
|>>>>>>        >>>>     - draft-ietf-patel-ecrit-sos-parameter
|>>>>>>        >>>>     - draft-ietf-sipcore-location-conveyance
|>>>>>>        >>>>     - draft-ietf-sipcore-keep
|>>>>>>        >>>>     - draft-ietf-sipcore-199
|>>>>>>        >>>>     - draft-bliss-call-completion
|>>>>>>        >>>>     - draft-ietf-mmusic-ice-tcp
|>>>>>>        >>>>     - draft-patel-dispatch-cpc-oli-parameter
|>>>>>>        >>>>     -
|>> draft-bakker-sipping-3gpp-ims-xml-body-handling
|>>>>>>        >>>>     - draft-kaplan-dispatch-session-id
|>>>>>>        >>>>     - draft-dawes-dispatch-mediasec-parameter?
|>>>>>>        >>>>     5. Review of 3GPP IETF dependency document
|>>>>>>        >>>>     - any comments on any other items in the
|>>>>> dependency list
|>>>>>>        >>>>     6. Next meeting
|>>>>>>        >>>>     7. AOB
|>>>>>>        >>>>     8. Closing
|>>>>>>        >>>>     *1. **ROLL CALL*
|>>>>>>        >>>>     All participants are listed above.
|>>>>>>        >>>>     *2. **REVIEW OF ACTION POINTS*
|>>>>>>        >>>>     *#*     *Old APs from previous meetings*
|>>>>>> *Responsible*
|>>>>>>        >  *Status*
|>>>>>>        >>>>     14      Talk with ECRIT chairs and Robert
|>>>>>> Sparks to make a
|>>>>>>        >  proposal on
|>>>>>>        >>>>     how and where the sos-parameter -draft
|>>>> should progress
|>>>>>>        >>>>     The current version is being reviewed in
|>>>>>> DISPATCH and then
|>>>>>>        >>>>     foreseen to proceed as AD sponsored draft
|>>>>>>        >>>>             Gonzalo         Closed
|>>>>>>        >>>>     15      Request for volunteers from 3GPP side
|>>>>>> to co-author
|>>>>>>        >>>>     draft-mmusic-ice-tcp    Atle    Closed
|>>>>>>        >>>>     16      Check with 3GPP LS officer why the LS
|>>>>>> C1-101810 was not
|>>>>>>        >>>>     distributed on DISPATCH list
|>>>>>>        >>>>     One way forward would be to provide an
|>>>>>> informational draft to
|>>>>>>        >>>>     document how things have been done
|>>>>>> historically. It was agreed
|>>>>>>        >>>>     that re-distribution of the LS is not necessary.
|>>>>>>        >>>>             Hannu   Closed
|>>>>>>        >>>>             *New APs assigned in this meeting*
|>>>>>>        >>>>     17      Agree during IETF #79 how to progress
|>>>>>> the work on
|>>>>>>        >>>>     draft-drage-sipping-rfc3455bis  Keith,
|>>>>>> Christer, Robert Open
|>>>>>>        >>>>     18      Decide between the editor, DISPATCH
|>>>>>> co-chairs and AD the
|>>>>>>        >  best
|>>>>>>        >>>>     approach to progress the work on
|>>>>>>        >>>>     draft-patel-dispatch-cpc-oli-parameter.
|>>>>>> Milan, Mary,
|>>>>>>        >  Cullen,
|>>>>>>        >>>>     Robert  Open
|>>>>>>        >>>>
|>>>>>>        >>>>
|>>>>>>        >>>>
|>>>>>>        >>>>     *3. ATOCA**WORK*
|>>>>>>        >>>>     Outside this meeting it has been agreed with
|>>>>>> ATOCA WG chairs
|>>>>>>        >  that
|>>>>>>        >>>>     Hannu Hietalahti will make a presentation of
|>>>>>> 3GPP Public Warning
|>>>>>>        >>>>     System in the ATOCA session in IETF #79. The
|>>>>>> presentation is
|>>>>>>        >>>>     being prepared in small expert group. The
|>>>>>> drafting group does
|>>>>>>        >  not
|>>>>>>        >>>>     follow any 3GPP WG borders but anyone who is
|>>>>>> willing to work on
|>>>>>>        >>>>     the presentation is invited to contact Hannu.
|>>>>>>        >>>>     *4. STALLED DRAFTS*
|>>>>>>        >>>>     *4.1 draft-drage-sipping-rfc**3455bis*
|>>>>>>        >>>>     This draft has been stalled due to low priority
|>>>>>> to drive it from
|>>>>>>        >>>>     3GPP side. Christer Holmberg volunteered to
|>>>>> help out as
|>>>>>>        >  co-editor
|>>>>>>        >>>>     to get the work done.
|>>>>>>        >>>>     It still needs to be agreed how to progress
|>>>>>> this draft. AP 17
|>>>>>>        >  was
|>>>>>>        >>>>     assigned to determine whether it can proceed as
|>>>>>> AD sponsored
|>>>>>>        >  draft?
|>>>>>>        >>>>     *4.2 draft-ietf-patel-ecrit-sos**-parameter*
|>>>>>>        >>>>     Extensibility mechanism has been removed and
|>>>>>> now it is reversed
|>>>>>>        >>>>     back to just URI parameter to indicate
|>>>>>> emergency registration.
|>>>>>>        >>>>     The latest draft does not take any position on
|>>>>>> how the special
|>>>>>>        >>>>     registration would be treated afterwards.
|>>>>> Misuse of URI
|>>>>>>        >  parameter
|>>>>>>        >>>>     is covered in the latest version, aiming at
|>>>>>> restricting the use
|>>>>>>        >>>>     of the special registration to emergency
|>>> case only.
|>>>>>>        >>>>     The 3GPP requirement is to identify special
|>>>>>> registration for
|>>>>>>        >>>>     emergency purposes.
|>>>>>>        >>>>     Possible re-naming of the draft was discussed
|>>>>>> to highlight that
|>>>>>>        >>>>     it has been recently treated in DISPATCH but no
|>>>>>> firm decision
|>>>>>>        >  was
|>>>>>>        >>>>     made on this yet.
|>>>>>>        >>>>     *4.3 draft-ietf-sipcore-location-conveyance*
|>>>>>>        >>>>     Authors intend to distribute a new version
|>>>>>> before IETF #79 to
|>>>>>>        >>>>     address the open issues that were identified in
|>>>>>> IETF #78 in
|>>>>>>        >>>>     Maastricht. The new version will be discussed
|>>>>>> in Beijing IETF.
|>>>>>>        >  If
|>>>>>>        >>>>     no new issues are raised, it is expected that
|>>>>>> the draft could go
|>>>>>>        >>>>     to WG LC in November or December.
|>>>>>>        >>>>     *4.4 draft-ietf-sipcore-keep*
|>>>>>>        >>>>     The draft has just finished WG last call and it
|>>>>>> has been moved
|>>>>>>        >  to
|>>>>>>        >>>>     IESG today.
|>>>>>>        >>>>     *4.5 draft-ietf-sipcore-199*
|>>>>>>        >>>>     This draft has been in IESG for a while and it
|>>>>>> has got stuck in
|>>>>>>        >  a
|>>>>>>        >>>>     discussion on what are the conditions when
|>>>>> this draft is
|>>>>>>        >  applicable.
|>>>>>>        >>>>     The editor is waiting for the comment from the
|>>>>>> AD (Robert
|>>>>>>        >  Sparks).
|>>>>>>        >>>>     *4.6 draft**-ietf-bliss-call-completion*
|>>>>>>        >>>>     The draft is now in WG LC which has already
|>>>>>> brought up some open
|>>>>>>        >>>>     issues. Dale Worley has got a list of open
|>>>>>> items and he will
|>>>>>>        >>>>     share them with the editor.
|>>>>>>        >>>>     *4.7 draft-ietf-mmusic-ice-tcp*
|>>>>>>        >>>>     There has been discussion on the 3GPP
|>>>>>> requirement for this. Now
|>>>>>>        >  a
|>>>>>>        >>>>     new editor has taken over the editorship of the
|>>>>>> draft and the
|>>>>>>        >>>>     work is ongoing again.
|>>>>>>        >>>>     Also an email comment on the foreseen way
|>>>>>> forward was received.
|>>>>>>        >>>>     The document authors have indicated there are
|>>>>>> currently no known
|>>>>>>        >>>>     issues and they have solicited a few reviewers.
|>>>>>> The authors
|>>>>>>        >>>>     expect to be ready for WGLC after the Beijing
|>>>>>> meeting (Nov
|>>>>>>        >  2010),
|>>>>>>        >>>>     assuming no new issues come up.
|>>>>>>        >>>>     *4.8 draft-patel-dispatch-cpc-oli-parameter*
|>>>>>>        >>>>     There have been no changes since Maastricht,
|>>>>>> where the feedback
|>>>>>>        >>>>     was not supportive at all. Informational draft
|>>>>>> that would
|>>>>>>        >>>>     document historically existing solution was
|>>>>>> seen as one possible
|>>>>>>        >>>>     way forward. However, Tel-URI parameters
|>>>>> would require a
|>>>>>>        >>>>     standards track document, so this point needs
|>>>>>> to be checked.
|>>>>>>        >>>>     AP 18 was assigned to determine the best
|>>>> way forward.
|>>>>>>        >>>>     *4.9
|>>>> draft-bakker-sipping-3gpp-ims-xml-body-handling*
|>>>>>>        >>>>     This draft has got a patent issue related with
|>>>>>> publication
|>>>>>>        >  number
|>>>>>>        >>>>     US 2009/0119382 A1, Bakker et al. which is
|>>>>>> dated May 7^th 2009.
|>>>>>>        >>>>     3GPP needs to know whether the draft can
|>>>>>> proceed to RFC or not
|>>>>>>        >>>>     and take appropriate actions based on that.
|>>>>>>        >>>>     *4.10 draft-kaplan-dispatch-session-id*
|>>>>>>        >>>>     This is the first candidate document for
|>>>>>> SIPSCOTCH. The charter
|>>>>>>        >>>>     text has been discussed but the group has not
|>>>>>> been chartered
|>>>>>>        >  yet.
|>>>>>>        >>>>     This matter has not progressed recently.
|>>>>>>        >>>>     Those interested in the chartering of the WG
|>>>>>> should contact the
|>>>>>>        >>>>     author of the draft to re-start the charter
|>>>>> discussion.
|>>>>>>        >>>>     *4.11 draft-dawes-dispatch-mediasec-parameter*
|>>>>>>        >>>>     On 3GPP side it is seen that DTLS-based
|>>>>>> solution is not seen to
|>>>>>>        >>>>     work in 3GPP environment, so another solution
|>>>>>> is needed. The
|>>>>>>        >>>>     editor has not received much feedback on the
|>>>>>> DISPATCH mailing
|>>>>>>        >>>>     list on his draft. The editor will re-post the
|>>>>>> draft to the list
|>>>>>>        >>>>     and those driving this work can then give their
|>>>>>> comments.
|>>>>>>        >>>>     *5. REVIEW OF 3GPP**- IETF DEPENDENCY DOCUMENT*
|>>>>>>        >>>>     *5.1 De**pendency document review during the
|>>>>>> teleconference*
|>>>>>>        >>>>     New version of
|>>>>>> draft-liess-dispatch-alert-info-urns has been
|>>>>>>        >>>>     distributed today.
|>>>>>>        >>>>     The author of
|>>>>>> draft-jesske-dispatch-reason-in-responses would
|>>>>>>        >>>>     need AD feedback from Gonzalo on how to proceed
|>>>>>> with the work.
|>>>>>>        >>>>     draft-ietf-simple-msrp-acm is waiting for AD
|>>>>>> go-ahead (Gonzalo
|>>>>>>        >>>>     Camarillo). So far this draft has been
|>>>>>> processed in sync with
|>>>>>>        >>>>     draft-ietf-simple-msrp-sessmatch, but it is
|>>>>>> being considered
|>>>>>>        >>>>     whether that linkage should be broken.
|>>>>>>        >>>>     The session matching draft
|>>>>>> (draft-ietf-simple-msrp-sessmatch)
|>>>>>>        >  has
|>>>>>>        >>>>     proven controversial both in earlier IETF
|>>>>>> discussions and in the
|>>>>>>        >>>>     IETF last call. It has now been sent back to WG
|>>>>>> to get consensus
|>>>>>>        >>>>     on how to proceed. This draft may require
|>>>> substantial
|>>>>>>        >  re-thinking
|>>>>>>        >>>>     before it can proceed.
|>>>>>>        >>>>     The status of draft-yu-tel-dai in the I-D
|>>>>>> tracker will be
|>>>>>>        >  checked
|>>>>>>        >>>>     by Robert Sparks together with Gonzalo
|>> Camarillo.
|>>>>>>        >>>>     Hannu volunteered to check the latest news on
|>>>>>>        >>>>     draft-das-mipshop-andsf-dhcp-options from
|>>>> Jari Arkko.
|>>>>>>        >>>>     draft-pkix-cmp-transport-protocols is also
|>>>>>> marked as critical,
|>>>>>>        >>>>     but no comments were made on it.
|>>>>>>        >>>>     Email comments were received on the
|>>>> following drafts.
|>>>>>>        >>>>     draft-mipshop-andsf-dhcp-options is in IESG
|>>>>>> evaluation with two
|>>>>>>        >>>>     discussions remaining. This is seen to require
|>>>>>> a straightforward
|>>>>>>        >>>>     update of the draft and the a review by
|>> Tim Polk.
|>>>>>>        >>>>     draft-ietf-mext-rfc3775bis is in AD review.
|>>>>>>        >>>>     draft-ietf-mext-nemo-pd is pending for author's
|>>>>>> changes since
|>>>>>>        >>>>     September. The discusses seem reasonable.
|>>>>>>        >>>>     *6. NEXT MEETING*
|>>>>>>        >>>>     Hannu will attend IETF #79 which makes a good
|>>>>>> opportunity for
|>>>>>>        >  the
|>>>>>>        >>>>     next status check-up.
|>>>>>>        >>>>     *7. ANY OTHER BUSINESS*
|>>>>>>        >>>>     None.
|>>>>>>        >>>>     *8. CLOSING*
|>>>>>>        >>>>     The meeting was closed at 16:20 UTC.
|>>>>>>        >>>>     BR,
|>>>>>>        >>>>     Hannu Hietalahti
|>>>>>>        >>>>     3GPP TSG CT Chairman
|>>>>>>        >>>>     tel: +358 40 5021724
|>>>>>>        >>>>     <ATT00001..c>
|>>>>>>        >>>
|>>>>>>        >>>
|>>>>>>        >>>     _______________________________________________
|>>>>>>        >>>     RAI mailing list
|>>>>>>        >>>     [email-masked]<mailto:[email-masked]>
|>>>>>>        >>>     https://www.ietf.org/mailman/listinfo/rai
|>>>>>>        >>>
|>>>>>>        >>>
|>>>>>>        >>
|>>>>>>        >>
|>>>>>>        >>
|>>>>>>        >>  _______________________________________________
|>>>>>>        >>  RAI mailing list
|>>>>>>        >>  [email-masked]
|>>>>>>        >>  https://www.ietf.org/mailman/listinfo/rai
|>>>>>>        >  _______________________________________________
|>>>>>>        >  RAI mailing list
|>>>>>>        >  [email-masked]
|>>>>>>        >  https://www.ietf.org/mailman/listinfo/rai
|>>>>>>
|>>>>>>
|>>>>>>
|>>>>>>
|>>>>>>
|>>>>>
|>>>>
|>>>
|>>
|>
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 3 Nov 2010 10:43:16 +0530

Paul/John,

Unique recording id is required for specific reasons as I mentioned in
the another mail thread:

SRC has to identify that CS are related to the single RS during the call
service like call transfer (REFER based). Usecase 4 illustrate the
change of CS change from Alice-Bob CS to Bob-carol CS and SRC has to
keep track of this change using UID.  Without UID, Bob-carol will be
considered as not part of the existing RS. This UID requirement requires
support of UA's involved in SIP recording. This is the common callflow
for call center deployment where agents will be keep changing within the
single session from the customer. 

The same id may be used for retrieving the session after the session is
completed. When it is used for retrieval, authorization policy has to be
applied. I thought of this identity as equivalent to webex recording
link after the conference is over. This information is not replacement
to inform UA about becoming recorded. 

Thanks
Partha 

-----Original Message-----
From: Paul Kyzivat (pkyzivat) 
Sent: Tuesday, November 02, 2010 11:35 PM
To: Elwell, John
Cc: Parthasarathi R (partr); Hadriel Kaplan; Rosen, Brian;
[email-masked]; Ram Mohan R (rmohanr); Ken Rehor (krehor)
Subject: Re: Session-id in SIPREC [Was RE: [RAI] Minutes of 3GPP - IETF
telco on the 19th of October]

	Thanks,
	Paul

>> identifier. It shows that the 4 entities involved (Alice, Bob, 
>> B2BUA/SRC and SRS) all receive the UID, but what do these entities 
>> use the UID for and what would be the consequences of some of the 
>> entities not receiving the UID? For example, if Alice and Bob are 
>> able to use the UID for later finding and replaying the recording, I 
>> guess that would be a good reason.
>>
>> <Partha>  The reason for this usecase is to illustrate that Call-id 
>> is not sufficient for UID and also as you mentioned to indicate the 
>> under the umbrella of the same UID used for the first CS. So this 
>> would provide the SRS with a link between the two CSs. If Alice, Bob 
>> or Carol later wants to find and replay the recording, they can use 
>> the UID to find the recording of the set of CSs, and presumably can 
>> select a particular CS to replay or replay the two in sequence.

>> [JRE] A similar authorization question. Is Carol's knowledge of the 
>> UID sufficient to allow Alice to access the entire CS between Alice 
>> and Bob, even that part when Alice was not a party?
>>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 3 Nov 2010 08:20:43 +0100

> Sent: 03 November 2010 05:13
> To: Paul Kyzivat (pkyzivat); Elwell, John
> Cc: Hadriel Kaplan; Rosen, Brian; [email-masked]; Ram Mohan 
> service like call transfer (REFER based). 
If CS recordings are delivered over the same RS, this will be apparent to the SRS without needing a separate identifier. However, the CS recordings will not necessarily be delivered over the same RS if, for example, the SRC chooses to use a different RS for each CS. It think the point you are trying to make is that there needs to be some means of grouping the CSs together. We did touch on the possibility of a CS group object a little while back.

So assuming the concept of a CS group, which implies some sort of CS group identifier, if the same SRC is used for all CSs in the group, the SRC can allocate the CS group identifier and signalling support for this on the CS path is not needed (and therefore Hadriel's session-ID, or some similar solution, is not needed).

It seems what we need to understand is whether there are situations where there are two or more SRCs recording two or more CSs that need to be considered to be in the same CS group. There would then perhaps be a need for signalling support on the CS path for transporting the CS group identifier. However, none of the use cases so far put forward show this, which suggests it is not a sufficiently important case.

John (as individual)

> Usecase 4 illustrate the

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 3 Nov 2010 15:51:39 +0530

John,

Please read inline.

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, November 03, 2010 12:51 PM
To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat)
Cc: Hadriel Kaplan; Rosen, Brian; [email-masked]; Ram Mohan R

> Cc: Hadriel Kaplan; Rosen, Brian; [email-masked]; Ram Mohan R 

> the another mail thread:
> 
> SRC has to identify that CS are related to the single RS during the 
> call service like call transfer (REFER based).
If CS recordings are delivered over the same RS, this will be apparent
to the SRS without needing a separate identifier. However, the CS
recordings will not necessarily be delivered over the same RS if, for
example, the SRC chooses to use a different RS for each CS. It think the
point you are trying to make is that there needs to be some means of
grouping the CSs together. We did touch on the possibility of a CS group
object a little while back.

<Partha> Yes, the main motive is to group the set of CS using unique
identifier. Hope everybody are in agreement for this requirement.
</partha>

So assuming the concept of a CS group, which implies some sort of CS
group identifier, if the same SRC is used for all CSs in the group, the
SRC can allocate the CS group identifier

<Partha> SRC shall allocate CS group identifier locally in case SRS
knows that two CS's are related by some means. Paul proposed the same
solution in the another mail thread. In case of usecase 4, SRS will not
aware that alice-bob CS and bob-carol CS are related with normal SIP
message. It is not possible for SRC to correlate CS without the unique
id. This scenario is same as troubleshooting session id issue where the
entities will not be able to correlate the session.

I noticed that this requirement is critical in terms of call centre
where Agents keep changing during the course of the single recording
session. One of the known solution for me is to use unique id in CS. In
case everyone feel that this scenario has to be taken care by
non-standard SIP mechanism, I'm fine with it. </Partha>

 and signalling support for this on the CS path is not needed (and
therefore Hadriel's session-ID, or some similar solution, is not
needed).

It seems what we need to understand is whether there are situations
where there are two or more SRCs recording two or more CSs that need to
be considered to be in the same CS group. 
<Partha> I'm also curious to here from everyone about this requirement.
I know of one realtime scenario for the same: IP phone within single
enterprise record the session to the same recorder. By default, two
recording will occur if there is no protocol means between two IP phone.
By enhancing the protocol, each SRC may decide to record its sending
media stream only instead of recording both receiving and sending media
stream or anyone of SRC will record at the given time.

As per our earlier discussion, the above mentioned scenario is outside
the scope of SIPREC </Partha> 

There would then perhaps be a need for signalling support on the CS path
for transporting the CS group identifier. However, none of the use cases
so far put forward show this, which suggests it is not a sufficiently
important case.

John (as individual)

> considered as not part of the existing RS. This UID requirement 
> requires support of UA's involved in SIP recording. This is the common

> callflow for call center deployment where agents will be keep changing

> within the single session from the customer.
> 
> The same id may be used for retrieving the session after the session 
> is completed. When it is used for retrieval, authorization policy has 
> to be applied. I thought of this identity as equivalent to webex 
> recording link after the conference is over. This information is not 
> replacement to inform UA about becoming recorded.
> 
> Thanks
> Partha

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 3 Nov 2010 11:42:22 +0100

> Sent: 03 November 2010 10:22
> To: Elwell, John; Paul Kyzivat (pkyzivat)
[JRE] I am not sure I understand. The way I see it, the SRC is aware that the two CSs are grouped, and needs to convey this to the SRS, e.g., by conveying a group-ID as part of the metadata. This would fall within the remit of SIPREC. However, this use case does not require any additional signalling on the CS signalling path, since there is only a single CS.

> non-standard SIP mechanism, I'm fine with it. </Partha>
[JRE] The use case as you describe it (with a single SRC at a B2BUA serving both agents) does not require a non-standard SIP mechanism, provided we include the group ID in the metadata conveyed to the SRS.

John (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Nov 2010 09:32:01 -0400

At the moment I am in agreement with John - that an ID assigned by the 
SRC is apparently sufficient for the use cases we have. I'm looking for 
evidence that we need more (and hoping we don't, because it will 
complicate things.)

	Thanks,
	Paul

On 11/3/2010 6:42 AM, Elwell, John wrote:
>> non-standard SIP mechanism, I'm fine with it.</Partha>
>> the scope of SIPREC</Partha>
>>

---

From: Leon Portman <[email-masked]>
Date: Wed, 3 Nov 2010 15:57:38 +0200

+1

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, November 03, 2010 3:32 PM
To: Elwell, John
Cc: Hadriel Kaplan; [email-masked]; Rosen, Brian
Subject: Re: [siprec] Session-id in SIPREC [Was RE: [RAI] Minutes of 3GPP - IETF telco on the 19th of October]

	Thanks,
	Paul

_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 4 Nov 2010 11:53:06 +0530

John/Paul,

I'm completely agree with you folks in case CS group by SRC by looking
at CS is outside the scope of SIPREC. IOW, Grouping of CS for the single
RS by SRC is outside the scope of SIPREC and SRC decides the group of
CS, add the unique identity in metadata for all CS by which SRS shall
retrieve the related CS as single group.  

I have added usecase-4 with more text for discussion. In usecase4, The
unique identify plays the role when Bob initiate the new dialog(INVITE)
towards carol through B2BUA. From B2BUA  perspective, new INVITE from
bob(CS2) is a new dialog towards carol, how B2BUA will relates this CS2
to CS1?

Thanks
Partha

-----Original Message-----
From: Paul Kyzivat (pkyzivat) 
Sent: Wednesday, November 03, 2010 7:02 PM
To: Elwell, John
Cc: Parthasarathi R (partr); Hadriel Kaplan; Rosen, Brian;

	Thanks,
	Paul

On 11/3/2010 6:42 AM, Elwell, John wrote:
>> If CS recordings are delivered over the same RS, this will be 
>> apparent to the SRS without needing a separate identifier. However, 
>> the CS recordings will not necessarily be delivered over the same RS 
>> if, for example, the SRC chooses to use a different RS for each CS.
>> It think the
>> grouping the CSs together. We did touch on the possibility of a CS 
>> group object a little while back.
>>

>> group identifier, if the same SRC is used for all CSs in the group, 
>> the SRC can allocate the CS group identifier
>>

>> solution in the another mail thread. In case of usecase 4, SRS will 
>> not aware that alice-bob CS and bob-carol CS are related with normal 
>> SIP message. It is not possible for SRC to correlate CS without the 
>> unique id. This scenario is same as troubleshooting session id issue 
>> where the entities will not be able to correlate the session.
> [JRE] I am not sure I understand. The way I see it, the SRC is aware
that the two CSs are grouped, and needs to convey this to the SRS, e.g.,
by conveying a group-ID as part of the metadata. This would fall within
the remit of SIPREC. However, this use case does not require any
additional signalling on the CS signalling path, since there is only a
single CS.
>> session. One of the known solution for me is to use unique id in CS. 
>> In case everyone feel that this scenario has to be taken care by 
> [JRE] The use case as you describe it (with a single SRC at a B2BUA
serving both agents) does not require a non-standard SIP mechanism,
provided we include the group ID in the metadata conveyed to the SRS.
>> where there are two or more SRCs recording two or more CSs that need 
>> to be considered to be in the same CS group.
>> media stream only instead of recording both receiving and sending 
>> media stream or anyone of SRC will record at the given time.
>>
>> As per our earlier discussion, the above mentioned scenario is 
>> outside the scope of SIPREC</Partha>
>>
>> There would then perhaps be a need for signalling support on the CS 
>> path for transporting the CS group identifier. However, none of the 
>> use cases so far put forward show this, which suggests it is not a 
>> sufficiently important case.
>>
>> John (as individual)
>>
>>> Usecase 4 illustrate the

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 4 Nov 2010 08:28:05 +0100

Partha,

Thanks. I see your point about use case 4 - Alice knows the two CSs are related, but how does the B2BUA and its SRC know? So this could be a requirement for grouping together a number of CSs under a common identifier. This is quite different from the problem being addressed by Hadriel's session-ID proposal, by the way. I can see that for basic consultation call and call transfer scenarios, Alice would be in control of deciding the grouping, by choosing whether to assign an existing group ID or a new group ID to a new CS.

I can also imagine some more complex cases where it might not be so clear how to handle a CS group ID. For example:
- where two CSs with different group IDs join the same conference;
- where Alice answers an incoming waiting CS that already has a group ID assigned while holding another CS that has a different group ID assigned and then transfers the two together;
- where Alice performs a pick-up on a call that already has a group ID assigned while holding another CS that has a different group ID assigned and then transfers the two together.

It can be done - there would just need to be some rules established at deployment time.

John (as individual)

> Sent: 04 November 2010 06:23

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Nov 2010 10:27:19 -0400

I wonder if these more complex CS grouping scenarios, where the need for 
grouping is known by a participant but not by the SRC, should be ruled 
out of scope *for now*, and then potentially considered at some later 
date. They seem to require a mechanism for communication and cooperation 
between participants and the SRC which is somewhat different than the 
rest of the stuff we are working on right now.

Some of the kinds of cases John calls out below may even call for 
hierarchical grouping, with differing access rules for the different groups.

	Thanks,
	Paul

---

From: "De Villiers de Wet" <[email-masked]>
Date: Thu, 4 Nov 2010 16:38:35 +0200

John

This is where my suggestion came in - instead of trying to determine THE
unique ID for a CS group, the SRC just 'publishes' the links between CSs
(each having its own unique ID) to the SRS, as far as it is able to do
so.  In a sense this makes it the problem of the SRS implementation to
decide what to do with the link info, i.e. it can create a single, or
multiple grouping identifiers to group RSs together (based on rules that
may be configurable), OR the SRS can just store the link information and
use it at playback& search time to link different CSs/RSs toghether,
perhaps based on user preference.

De Villiers

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 04 November 2010 09:28
To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat)
Cc: Rosen, Brian; Hadriel Kaplan; [email-masked]
Subject: Re: [siprec] Session-id in SIPREC [Was RE: [RAI] Minutes of

Partha,

Thanks. I see your point about use case 4 - Alice knows the two CSs are
related, but how does the B2BUA and its SRC know? So this could be a
requirement for grouping together a number of CSs under a common
identifier. This is quite different from the problem being addressed by
Hadriel's session-ID proposal, by the way. I can see that for basic
consultation call and call transfer scenarios, Alice would be in control
of deciding the grouping, by choosing whether to assign an existing
group ID or a new group ID to a new CS.

I can also imagine some more complex cases where it might not be so
clear how to handle a CS group ID. For example:
- where two CSs with different group IDs join the same conference;
- where Alice answers an incoming waiting CS that already has a group ID
assigned while holding another CS that has a different group ID assigned
and then transfers the two together;
- where Alice performs a pick-up on a call that already has a group ID
assigned while holding another CS that has a different group ID assigned
and then transfers the two together.

It can be done - there would just need to be some rules established at
deployment time.

John (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Nov 2010 11:11:26 -0400

> perhaps based on user preference.

In the current metamodel the mechanism for accomplishing the linkages is 
unspecified. So what you suggest is just a different way of describing 
the same thing. Either way the SRC needs to track the different CSs and 
identify the desired linkages.

How this is accomplished with be important when we get to describing how 
the metadata is communicated from SRC to SRS.

A *fundamental* difference is whether the same CS can be associated with 
more than one group. In principle we could allow for an arbitrary mesh 
of associations between CSs. But that is probably overkill.

An advantage of having a grouping construct, rather than just directly 
associating one CS with another, is that it provides a place to hang 
extra attributes - such as the reason these CSs are grouped together. We 
don't currently have any explicit ones specified, but there is provision 
for application-specific ones.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 4 Nov 2010 13:38:08 -0700

Hi Partha,

I don't think we have to tie the related CSes into a single RS and allow
the B2BUA to use a different RS to record the bob-carol call segment. As
long as the SRC is aware of the group identifier, the SRC can just
attach that to the CS. 

Otherwise I am fine with the approach to have a group identifier for
related CSes. Can a CS have more than one of these group identifiers if
the CS is related to more than one CS group? 

Regards,
Henry

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Parthasarathi R (partr)
> Sent: Thursday, November 04, 2010 2:23 AM
> 3GPP -IETF telco on the 19th of October]
> 
> John/Paul,
> 
> at CS is outside the scope of SIPREC. IOW, Grouping of CS for the
> single RS by SRC is outside the scope of SIPREC and SRC decides the
> group of CS, add the unique identity in metadata for all CS by which
> SRS shall retrieve the related CS as single group.
> 
IETF
> that the two CSs are grouped, and needs to convey this to the SRS,
> e.g., by conveying a group-ID as part of the metadata. This would fall
> within the remit of SIPREC. However, this use case does not require
any
> >>> replacement to inform UA about becoming recorded.

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 4 Nov 2010 13:47:14 -0700

I was just asking a related question. Please see inline.

> Behalf Of Paul Kyzivat
> Sent: Thursday, November 04, 2010 11:11 AM
> To: De Villiers de Wet
> Cc: [email-masked]; Hadriel Kaplan; Rosen,Brian

[[hlum]] A CS can be associated with more than one group, if you
consider a participant having multiple conversations with different
people. For example, a consultation transfer may have the caller
speaking with the transferred party first before completing the
transfer, then the caller may be considered to part of two separate
groups: one for callee, and one for transferred party. 

> > - where Alice answers an incoming waiting CS that already has a
group
> ID
> >> additional signalling on the CS signalling path, since there is
only

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Nov 2010 17:05:12 -0400

> the CS is related to more than one CS group?

I'm looking for an answer to that question.
I think we know that CSs need to be grouped or related in some cases. 
But I don't have a clear understanding of how complex that grouping 
needs to be. E.g. whether a single CS might need to be in more than one 
group, or if the specific roles of CSs within a group need to be 
identified. We need to provide *enough* structure to handle this stuff, 
but I think we want to avoid adding unnecessary complexity.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Mon, 8 Nov 2010 03:35:03 +0200

We should also remember that these grouped together CSes are not always overlapping in time: like blind transfers.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, November 04, 2010 11:05 PM
To: Henry Lum
Cc: [email-masked]; Hadriel Kaplan; Rosen, Brian
Subject: Re: [siprec] Session-id in SIPREC [Was RE: [RAI] Minutes of 3GPP -IETF telco on the 19th of October]

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Nov 2010 20:45:29 -0500

definitely