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

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

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