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

["Muthu ArulMozhi Perumal (mperumal)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On
Behalf Of
|Paul Kyzivat (pkyzivat)
|Sent: Tuesday, November 02, 2010 11:35 PM
|To: Elwell, John
|Cc: Hadriel Kaplan; [e-mail]; 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:[e-mail]]
|>> Sent: 02 November 2010 16:45
|>> To: Elwell, John; Hadriel Kaplan
|>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [e-mail];
|>> 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:[e-mail]]
|>> Sent: Monday, November 01, 2010 2:59 PM
|>> To: Parthasarathi R (partr); Hadriel Kaplan
|>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [e-mail];
|>> 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:[e-mail]]
|>>> Sent: 01 November 2010 08:45
|>>> To: Elwell, John; Hadriel Kaplan
|>>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [e-mail];
|>> 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:[e-mail]]
|>>> Sent: Thursday, October 28, 2010 6:59 PM
|>>> To: Parthasarathi R (partr); Hadriel Kaplan
|>>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [e-mail];
|>> 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:[e-mail]]
|>>>> Sent: 28 October 2010 12:36
|>>>> To: Elwell, John; Hadriel Kaplan
|>>>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [e-mail];
|>>> 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:[e-mail]]
|>>>> Sent: Thursday, October 28, 2010 3:42 PM
|>>>> To: Parthasarathi R (partr); Hadriel Kaplan
|>>>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [e-mail];
|>>> 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:[e-mail]]
|>>>>> Sent: 28 October 2010 09:59
|>>>>> To: Elwell, John; Hadriel Kaplan
|>>>>> Cc: Paul Kyzivat (pkyzivat); Rosen, Brian; [e-mail];
|>>>> 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:[e-mail]]
|>>>>> Sent: Thursday, October 28, 2010 1:22 PM
|>>>>> To: Parthasarathi R (partr); Hadriel Kaplan
|>>>>> Cc: Paul Kyzivat (pkyzivat); [e-mail]; 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:[e-mail]]
|>>>>>> Sent: 28 October 2010 07:21
|>>>>>> To: Hadriel Kaplan
|>>>>>> Cc: Paul Kyzivat (pkyzivat); [e-mail]; 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:[e-mail]]
|>>>>>> Sent: Thursday, October 28, 2010 10:52 AM
|>>>>>> To: Parthasarathi R (partr)
|>>>>>> Cc: Paul Kyzivat (pkyzivat); [e-mail];
|>>>>>> [e-mail]
|>>>>>> 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:[e-mail]]
|>>>>>>        Sent: Wed 10/27/2010 7:35 PM
|>>>>>>        To: Parthasarathi R (partr)
|>>>>>>        Cc: Paul Kyzivat (pkyzivat); [e-mail]
|>>>>>>        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: [e-mail]
|>>> [mailto:[e-mail]]
|>>>>>> On Behalf Of
|>>>>>>        >  Paul Kyzivat (pkyzivat)
|>>>>>>        >  Sent: Tuesday, October 26, 2010 9:44 PM
|>>>>>>        >  To: [e-mail]
|>>>>>>        >  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
|>>>>>>        >>>  <[e-mail]
|>>>>>> <mailto:[e-mail]>>  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,
|>>>>> <[e-mail]
|>>>>>>        >>>     <mailto:[e-mail]>>
|>>>>>> <[e-mail]
|>>>>>>        >>>     <mailto:[e-mail]>>  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: [phone]
|>>>>>>        >>>>     <ATT00001..c>
|>>>>>>        >>>
|>>>>>>        >>>
|>>>>>>        >>>     _______________________________________________
|>>>>>>        >>>     RAI mailing list
|>>>>>>        >>>     [e-mail]<mailto:[e-mail]>
|>>>>>>        >>>     https://www.ietf.org/mailman/listinfo/rai
|>>>>>>        >>>
|>>>>>>        >>>
|>>>>>>        >>
|>>>>>>        >>
|>>>>>>        >>
|>>>>>>        >>  _______________________________________________
|>>>>>>        >>  RAI mailing list
|>>>>>>        >>  [e-mail]
|>>>>>>        >>  https://www.ietf.org/mailman/listinfo/rai
|>>>>>>        >  _______________________________________________
|>>>>>>        >  RAI mailing list
|>>>>>>        >  [e-mail]
|>>>>>>        >  https://www.ietf.org/mailman/listinfo/rai
|>>>>>>
|>>>>>>
|>>>>>>
|>>>>>>
|>>>>>>
|>>>>>
|>>>>
|>>>
|>>
|>
|_______________________________________________
|siprec mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/siprec