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

["Parthasarathi R (partr)" <[e-mail]>]

 
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
>
>
>
>
>

--- Begin Message ---

inline

-----Original Message-----
From: Parthasarathi R (partr) [mailto:[e-mail]] 
Sent: 20 October 2010 07:27
To: Elwell, John; Ram Mohan R (rmohanr); De Villiers de Wet
Cc: [e-mail]
Subject: RE: [siprec] Metadata Open item : Communication Session
Attributes

Please read inline. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Elwell, John
Sent: Tuesday, October 19, 2010 1:19 PM
To: Ram Mohan R (rmohanr); De Villiers de Wet
Cc: [e-mail]
Subject: Re: [siprec] Metadata Open item : Communication Session
Attributes


 

> -----Original Message-----
> From: Ram Mohan R (rmohanr) [mailto:[e-mail]]
> Sent: 18 October 2010 18:12
> To: De Villiers de Wet; Elwell, John
> Cc: [e-mail]
> Subject: RE: [siprec] Metadata Open item : Communication Session 
> Attributes
> 
> Hi De Villers,
> 
>  
> 
> Please see inline <Ram>
> 
>  
> 
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of De Villiers de Wet
> Sent: Monday, October 18, 2010 6:17 PM
> Cc: [e-mail]
> Subject: Re: [siprec] Metadata Open item : Communication Session 
> Attributes
> 
>  
> 
> Good day
> 
>  
> 
> Please see my comments inline.
> 
>  
> 
> De Villiers de Wet (DdW)
> 
>  
> 
> From: Ram Mohan R (rmohanr) [mailto:[e-mail]]
> Sent: 15 October 2010 15:54
> To: [e-mail]
> Subject: [siprec] Metadata Open item : Communication Session 
> Attributes
> 
>  
> 
> Hi Team,
> 
>  
> 
> We got comments in alias as well as in the interim meeting from Leon 
> to have attributes like Direction, Initiator, call ID  as some of the 
> attributes for Communication Session.
> 
>  
> 
> Depending on where the SRC is located the direction may have some 
> significance. E.g SBC located at a edge of an Enterprise may know 
> whether is incoming/outgoing. Otherwise in a lot of 3PCC situations, 
> the UA is the recipient of the INVITE request, even if the user 
> requested the call. Also, if the call is established by transfer from 
> somebody else, it might always be incoming from the perspective of the

> local user but might also be incoming from the perspective of the 
> remote user. So it may be tricky to find the direction.
> 
>  
> 
> Does the wider team see a value in having direction attribute ?
> 
> [DdW] Yes, many clients of recording systems are interested in this 
> attribute.  Another related attribute is the call 'scope', i.e. 
> whether it is an internal call (all participating parties are 
> internal) or an 'external' call, i.e. at least one party is an 
> external party.  Of course the Direction and Scope attributes cannot 
> always be determined, or determined reliably, but that should not 
> prevent the standard from making provision for it, including the 
> provision for 'Unknown' values.  Be aware that many end-users mix the 
> two concepts together and make a distinction as
> follows:  incoming (from external party to an internal party), 
> outgoing (reverse of previous) and internal.  How to present the two 
> concepts to the end-user is the responsibility of the SRS in my view, 
> i.e. should not be part of the standard.
> 
>  
> 
> What about Initiator attribute?
> 
> [DdW] I presume this is the same as identifying the Caller in 
> traditional telephony.  This attribute is even more important than the

> above ones, and will almost always be known by the SRC.  First it is 
> important to enable the user to understand a complex scenario, e.g. 
> transfer and conference, properly, as well as a scenario of several 
> calls over time, e.g.
> emergency room scenario - the sequence of who called who at what time 
> and after/before other calls.  Secondly, the attribute can be used 
> when finding calls for performance evaluation purposes, e.g. if a call

> center agent handles both inbound and outbound call types, it is 
> important to be able to find a selection of both inbound and outbound 
> calls with respect to the agent being evaluated.
> 
>  
> 
> <Ram> Makes sense.  I am fine adding Direction and Initiator 
> as CS attributes to the model.
> 
> I am not yet clear on what value does 'Scope' can add to the 
> model and to SRS ? Do you have any examples on why we need to 
> know the scope at SRS ?
[JRE] I think the problem with both direction indicator and scope is
that this is application information not available in SIP. SIP might
provide a clue, but in some cases that might be misleading. Perhaps we
need to explore making provision in the metadata for application
information, where this can be obtained by non-standardized means. I
would like to hear the views of the rest of the group on this.
<Partha> Agreed. It is possible to provide the initiator and direction
in two party call using UA and B2BUA. It may be complicated in case of
conference. </Partha>

[DdW] The majority of recorded calls are simple calls where direction,
initiator,
termination reason, etc. are known and can be provided.  In my view its
best to cater for it in a standard
way, and not let the difficult cases like conferences prevent a standard
way being defined for the typical case.

> 
>  
> 
> Regarding Call ID I feel it may have issues in case there is 
> a B2BUA. So should we look to have call ID in the model  OR 
> some other unique ID ?
> 
> [DdW] Some telephony systems have the concept of a globally 
> unique call ID, which becomes a central ID that multiple 
> applications that integrate with the telephony system use as 
> a central 'hook', without integrations having to be done 
> *between* the applications to perform the real-time linking 
> of different kinds of data, e.g. a transaction in the CRM 
> system and a voice recording.  This is a powerful concept.  
> For example, both the CRM system and recording system capture 
> the unique call ID real-time and store it.  Afterwards, if 
> someone wants to play back the recording(s) related to a 
> particular transaction, the list of unique call IDs stored by 
> the CRM system can be used to find and play the recordings 
> tagged with these IDs. 
> 
>  
> 
>  I don't think the standard must specify that it must be a 
> globally unique identifier; it must just cater for such an 
> ID, including the 'Unknown' value.
> 
>  
> 
> <Ram> I see a value in having a unique ID. But I don't think 
> it should be Call ID for various reasons. I will wait for 
> inputs from wider team to see what we can have as an unique 
> Identifier.
[JRE] There have been one or two initiatives to standardize a call
identifier in SIP, most recently the session-id proposal (proposed
SIPSCOTCH WG), which seems to have gone quiet recently. That proposal
had a limited scope (troubleshooting), which may or may not make it
unsuitable for SIPREC use. In fact there was discussion back in August
of the use of session-id for SIPREC, largely in the context of allowing
correlation between RSs from different SRC intances.
<Partha> This is the main reason, I was asking for session id. Session
id will use to correlate CS involved in the recording session
particularly when B2BUA acts as SRC. I'm not seeing SIPSCOTCH WG
discussed in dispatch during IETF-79. In case required, we will again
initiate the thread for more discussion during IETF-79. </Partha>

[DdW] I did not mention that the concept of a globally 
unique call ID I referred is from the CTI world.  Since SIPREC, and SIP
in
general seems to be replacing CTI protocols and interfaces, users of 
recording systems and integrators have a need for an equivalent concept
in SIPREC.
 
>  
> 
> What other attributes of CS can be put in the Metadata model  ? 
> 
> [DdW] See my comment about Call Scope above.
> 
>  
> 
> Call Termination Reason - for some customers knowing who 
> terminated the call (external party or internal) is very 
> important, e.g. to check if the correct end of call 
> 'protocol' is followed.
> 
> <Ram> Call Termination reason along with who terminated the 
> call seems a useful attribute to have in CS block.  
[JRE] "Who terminated the call" is another example of application
information that is not necessarily available (reliably) from SIP.
<Partha> Reason header in BYE may provide the required information.
Direction of BYE may indicate "who terminated the call" in two party
call. Again, this is fuzzy in terms of conference or multi-party call.
</Partha>

> 
>  
> 
> Who was/is the participants in a given media recording and 
> *at what time* is very important, e.g. for proper access 
> control to recordings afterwards.  E.g., if A and B take part 
> in a conference call, and B drops out of the call halfway, B 
> must NOT afterwards have access to the audio of the call for 
> the portion he/she was not taking part.  Only the SRC can 
> provide this info to the SRS, and if it does not, enforcing 
> proper access control in the SRS is a major problem.  So, an 
> important attribute of the participant of a CS/RS is 
> Participation Start Time (when started participating) and 
> Participation Duration (how long did he/she participate).  Of 
> course the SRS can 'measure' these by capturing the time of 
> the events that indicate the start/end of participation as/if 
> they arrive in real-time.  So depending on what is agreed 
> upon in terms of events sent to the SRS, it will be the job 
> of the SRC to provide it or the SRS to 'figure it out' from 
> the events.
> 
>  
> 
> Participant Name - often communication systems have a 
> configured friendly name for an endpoint, e.g. 'John Doe' for 
> extension 2110, or 'Sally Smith' for [e-mail].  
> If this is available to the SRC and passed to the SRS, it 
> enriches the value and content of the RS.
> 
>  
> 
> <Ram> The current Metadata model facilitates recording 
> participant information [ in participant block] and associate 
> it with the Received Media Stream block that will have media 
> properties.
> 
> This will have attributes like Start time/End time which you 
> have mentioned above.  Please let us know if that is sufficient.
> 
> Regarding your second comment on who can access what portions 
> of stored data,  I am not sure if it is in scope of SIPREC at 
> this point and if that needs to captured in the model.
> 
> I will wait for comments from wider team on this point.
[JRE] I think it depends what we are talking about. Information that the
SRC has regarding privacy of information to be recorded is, I believe,
within the scope of SIPREC. Authorisation procedures for somebody trying
to access a recording are outside the scope of SIPREC.
<Partha> Agreed </Partha>

John

> 
>  
> 
> Thanks,
> 
> Ram
> 
>  
> 
>  
> 
> Regards,
> 
> Ram
> 
>  
> 
> 
_______________________________________________
siprec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/siprec

--- End Message ---