Re: [RAI] Minutes of 3GPP - IETF telco on the 19th of October

[Peter Musgrave <[e-mail]>]

HI Partha,

SIPCLF does not by default provide any indication of dialog correlation in
the logging. Having a standard way to do that in SIPCLF logs may be a good
idea - but it has not been discussed there so far.

Regards,

Peter Musgrave

On Wed, Oct 27, 2010 at 11:30 PM, Parthasarathi R (partr)
<[e-mail]>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]<[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]<[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]>>> <
> [e-mail]
> >>>    <mailto:[e-mail] <[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] <[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
>
>
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai
>
>