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

From: <[email-masked]>
Date: Fri, 22 Oct 2010 15:32:37 +0200

Dear all,

please find the minutes of the 3GPP - IETF  telco earlier this week.

Date: 19th 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-rfc3455bis
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 7th 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     Dependency document review during the teleconference
New version of draft-liess-dispatch-alert-info-urns has been distributed today.

The author of draft-jesske-dispatch-reason-in-responses would need AD feedback from Gonzalo on how to proceed with the work.
draft-ietf-simple-msrp-acm is waiting for AD go-ahead (Gonzalo Camarillo). So far this draft has been processed in sync with draft-ietf-simple-msrp-sessmatch, but it is being considered whether that linkage should be broken.
The session matching draft (draft-ietf-simple-msrp-sessmatch) has proven controversial both in earlier IETF discussions and in the IETF last call. It has now been sent back to WG to get consensus on how to proceed. This draft may require substantial re-thinking before it can proceed.

The status of draft-yu-tel-dai in the I-D tracker will be checked by Robert Sparks together with Gonzalo Camarillo.

Hannu volunteered to check the latest news on draft-das-mipshop-andsf-dhcp-options from Jari Arkko.

draft-pkix-cmp-transport-protocols is also marked as critical, but no comments were made on it.

Email comments were received on the following drafts.

draft-mipshop-andsf-dhcp-options is in IESG evaluation with two discussions remaining. This is seen to require a straightforward update of the draft and the a review by Tim Polk.

draft-ietf-mext-rfc3775bis is in AD review.

draft-ietf-mext-nemo-pd is pending for author's changes since September. The discusses seem reasonable.

6.      Next meeting
Hannu will attend IETF #79 which makes a good opportunity for the next status check-up.

7.      Any other business
None.

8.      Closing
The meeting was closed at 16:20 UTC.

BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: +358 40 5021724

---

From: Mary Barnes <[email-masked]>
Date: Fri, 22 Oct 2010 17:03:40 -0500

Hi Hannu et al,

I have a couple of comments on the minutes and I apologize that I missed the
meeting due to an error when adding it to my calendar.

1) On AP18, we actually "dispatched" *draft-patel-dispatch-cpc-oli-parameter
*  in Maastricht. Per the meeting summary:
http://www.ietf.org/proceedings/78/minutes/dispatch.html
Conclusion:  There is not interest in adopting this work as is. The
recommendation is to go back to the general problem and describe the use
cases (Action: Brian Rosen)  such that an optimal solution can be developed.

2) The  draft-yu-tel-dai was discussed at the same time as the cpc-oli
document in Maastricht, thus, the same conclusion applies.

Regards,
Mary
DISPATCH WG co-chair
--p.s. sorry I missed the call, I had it in my calendar at the wrong time (I
can't do timezone math well).

On Fri, Oct 22, 2010 at 8:32 AM, <[email-masked]> wrote:

> *Date:* 19th 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,
>
> *Agenda:*
> *1.      **Roll call*
> *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.
>
> 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*
> *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.
>
> *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.
> *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 7th 2009.
> *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*
> 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.
>
> Hannu volunteered to check the latest news on
> draft-das-mipshop-andsf-dhcp-options from Jari Arkko.
>
> 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-nemo-pd is pending for author’s changes since September.
> The discusses seem reasonable.
>
> *6.      Next meeting*
> *7.      Any other business*
> *8.      Closing*
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Oct 2010 10:38:04 -0400

Hi,
I see the topic of session-id and SIPSCOTCH came up in this meeting.  I've tried getting it chartered, but it appears there isn't consensus that the narrow topic I want to focus on (troubleshooting) is what other people care about.
(well... not for people in the IETF anyway - I get constant queries about this draft mechanism from service providers, but they don't generally join nor comment in IETF mailing lists)

So I don't really know what to do, other than just implement it and convince some other vendors to as well, and avoid the IETF.  The IETF just isn't a good place for dealing with operational issues in SIP, afaict.

-hadriel

On Oct 22, 2010, at 9:32 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Date: 19th October 2010
Time: 15:00 – 17:00 UTC
Venue: Phone conference
Participants:

Agenda:
-------------
1. Roll call
1.      ROLL CALL

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

4.      STALLED DRAFTS

5.      REVIEW OF 3GPP – IETF DEPENDENCY DOCUMENT

draft-ietf-mext-nemo-pd is pending for author’s changes since September. The discusses seem reasonable.

6.      NEXT MEETING

7.      ANY OTHER BUSINESS
None.

8.      CLOSING

BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: +358 40 5021724

<ATT00001..c>

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 26 Oct 2010 10:59:31 -0400

Hi Hadriel,

I have implemented this as well. It has utility in a non-trouble shooting
context in my application.

I think the issue in IETF was that we fell into the "solve world hunger"
trap. SIPREC through they might find it useful for session correlation but
in a pure SIP sense this mechanism does not guarantee dialog correlation...

Peter Musgrave

On Tue, Oct 26, 2010 at 10:38 AM, Hadriel Kaplan <[email-masked]>wrote:

>
> Hi,
> I see the topic of session-id and SIPSCOTCH came up in this meeting.  I've
> tried getting it chartered, but it appears there isn't consensus that the
> narrow topic I want to focus on (troubleshooting) is what other people care
> about.
> (well... not for people in the IETF anyway - I get constant queries about
> this draft mechanism from service providers, but they don't generally join
> nor comment in IETF mailing lists)
>
> So I don't really know what to do, other than just implement it and
> convince some other vendors to as well, and avoid the IETF.  The IETF just
> isn't a good place for dealing with operational issues in SIP, afaict.
>
> -hadriel
>
>
> On Oct 22, 2010, at 9:32 AM, <[email-masked]> <
> [email-masked]> wrote:
>
> Dear all,
>
> *1.      **ROLL CALL*
> *2.      **REVIEW OF ACTION POINTS*
> *#**Old APs from previous meetings**Responsible**Status*14Talk with ECRIT
> chairs and Robert Sparks to make a proposal on how and where the
> GonzaloClosed15Request for volunteers from 3GPP side to co-author
> draft-mmusic-ice-tcpAtleClosed16Check with 3GPP LS officer why the LS
> HannuClosed *New APs assigned in this meeting*  17Agree during IETF #79
> how to progress the work on draft-drage-sipping-rfc3455bisKeith, Christer,
> RobertOpen18Decide 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, RobertOpen
>
>
> *3.      ATOCA** WORK*
> *4.      STALLED DRAFTS*
> *5.      REVIEW OF 3GPP **– IETF DEPENDENCY DOCUMENT*
> *6.      NEXT MEETING*
> *7.      ANY OTHER BUSINESS*
> *8.      CLOSING*

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Oct 2010 11:39:52 -0400

The problem with using session-id for anything else is: for every other use-case discussed so far, I can easily imagine situations where a middlebox would need to change the session-id to make things work, thereby negating its troubleshooting value.

-hadriel

On Oct 26, 2010, at 10:59 AM, Peter Musgrave wrote:

Hi Hadriel,

I have implemented this as well. It has utility in a non-trouble shooting context in my application.

I think the issue in IETF was that we fell into the "solve world hunger" trap. SIPREC through they might find it useful for session correlation but in a pure SIP sense this mechanism does not guarantee dialog correlation...

Peter Musgrave

On Tue, Oct 26, 2010 at 10:38 AM, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

-hadriel

Dear all,

Date: 19th October 2010
Time: 15:00 – 17:00 UTC
Venue: Phone conference
Participants:

Agenda:
-------------
1. Roll call

3.      ATOCA WORK

4.      STALLED DRAFTS

6.      NEXT MEETING

7.      ANY OTHER BUSINESS
None.

8.      CLOSING

BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: +358 40 5021724

<ATT00001..c>

_______________________________________________
RAI mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rai

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Oct 2010 12:14:21 -0400

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
>
>> I think the issue in IETF was that we fell into the "solve world
>> hunger" trap. SIPREC through they might find it useful for session
>> correlation but in a pure SIP sense this mechanism does not guarantee
>> dialog correlation...
>>
>> Peter Musgrave
>>
>> On Tue, Oct 26, 2010 at 10:38 AM, Hadriel Kaplan
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>     Hi,
>>     I see the topic of session-id and SIPSCOTCH came up in this
>>     meeting. I've tried getting it chartered, but it appears there
>>     isn't consensus that the narrow topic I want to focus on
>>     (troubleshooting) is what other people care about.
>>     (well... not for people in the IETF anyway - I get constant
>>     queries about this draft mechanism from service providers, but
>>     they don't generally join nor comment in IETF mailing lists)
>>
>>     So I don't really know what to do, other than just implement it
>>     and convince some other vendors to as well, and avoid the IETF.
>>     The IETF just isn't a good place for dealing with operational
>>     issues in SIP, afaict.
>>
>>     -hadriel
>>
>>
>>     On Oct 22, 2010, at 9:32 AM, <[email-masked]
>>     <mailto:[email-masked]>> <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>>     Dear all,
>>>     *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
>>>     *#*	*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
>>>     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
>>>     *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*
>>>     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?
>>>     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.
>>>     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.
>>>     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.
>>>     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.
>>>     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.
>>>     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.
>>>     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.
>>>     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.
>>>     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*
>>>     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.
>>>     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-nemo-pd is pending for author’s changes since
>>>     September. The discusses seem reasonable.
>>>     *6. NEXT MEETING*
>>     [email-masked] <mailto:[email-masked]>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 27 Oct 2010 15:20:06 +0530

Hadriel,

In terms of SIP SBC, any unique ID or header or body will be removed or
modified whether it is for troubleshooting or for any other application
purpose. 

Let us take the troubleshooting application itself. What is the
requirement for Enterprise SBC to pass the troubleshooting-id to service
provider network in case SBC acts as UA or IMS UE to service provider
network? Being the border element, SBC may wish to put the new
troubleshooting id (hiding session-id) to the outgoing dialog for the
same session rather than passing the existing troubleshooting id.  

I agree that the unique identification for the session is required in
different SIP application for different requirements. I'm seeing lot of
requirement in Enterprise deployment other than troubleshooting and
also, noticed the unique-id requirement in SIPREC to identify the group
of communication session. 

Until otherwise SBC or any other middle box (B2BUA/Focus) decides to
pass the specific header(s) based on standard, this unique-id approach
will never fly. 

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat (pkyzivat)
Sent: Tuesday, October 26, 2010 9:44 PM
To: [email-masked]
Subject: Re: [RAI] Minutes of 3GPP - IETF telco on the 19th of October

	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, 

>>>     *Time:*15:00 - 17:00 UTC
>>>     draft-patel-dispatch-cpc-oli-parameter. 	Milan, Mary,
Cullen,
>>>     Robert	Open
>>>     The draft has just finished WG last call and it has been moved
to
>>>     IESG today.
>>>     *5. REVIEW OF 3GPP**- IETF DEPENDENCY DOCUMENT*
>>>     draft-ietf-mext-nemo-pd is pending for author's changes since
>>>     Hannu will attend IETF #79 which makes a good opportunity for
the
>>>     next status check-up.

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 27 Oct 2010 07:58:21 -0400

HI Hadriel,

Is there any utility in solving this issue with standard logging (as opposed
to leaving breadcrumbs in SIP messages)?

If there was a standard logging format on SBCs/UAs and a standard way to log
a correlation between call legs through a B2BUA/SBC would this meet your
needs - or does it need to be actually "in the stream"?

Regards,

Peter Musgrave

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 27 Oct 2010 09:48:55 -0400

On Oct 27, 2010, at 7:58 AM, Peter Musgrave wrote:

> HI Hadriel, 
> 
> Is there any utility in solving this issue with standard logging (as opposed to leaving breadcrumbs in SIP messages)?
> 
> If there was a standard logging format on SBCs/UAs and a standard way to log a correlation between call legs through a B2BUA/SBC would this meet your needs - or does it need to be actually "in the stream"?

Nope, it needs to be in the actual messages.  Unlike every other use-case people have talked about, the benefit of a session-id is not just so that a single system can detect/log that two messages/dialogs with different call-id's are really the same call.  The session-id isn't really about benefiting a single system to begin with - it's about letting an operator or monitoring system correlate logs from different systems and see that it's the same call, or so that the operator of domain-A can contact the operator of domain-B and say "why did the call with session-id 12345 fail?".  

Of course if every call-id-changing system logged the message and the before/after call-id, and the operators were to go get every log of every system in the path to determine the mapping, then you could do the same thing without a session-id.  That's what happens today.  It's tedious, laborious, and painful.  Session-id is just a simple way to avoid that.  This is probably more of an issue/aid for Service Providers than Enterprise admins, because of the number of systems involved and volume of logs, but my guess is it would be useful for both.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 27 Oct 2010 10:05:44 -0400

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

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 28 Oct 2010 09:00:15 +0530

Hadriel,

SBC removing the header in the incoming SIP message and forming the new outgoing message is the default behavior and it is nothing to do with session-id proposal. Session-id IETF RFC will help SBC to design for passing across the specific header in the forthcoming release. Which forthcoming release (after 3 years or 10 years) depends upon the compelling reason for this header in specific SBC or other SIP device as we have number of SIP RFC today to implement. 

AFAIK, most of the companies create their own unique session id to identify the session and using it within their network for different purposes. Standardizing session id SIP header makes all the companies to interop in case the purpose of the specific company's unique session id is not broken. IMO, troubleshooting is one of the usecase which has workaround by building the appropriate logging mechanism and tools to analyze the log across the device. I guess that SIPCLF WG addresses this requirement. If troubleshooting is the only scope of the session-id, the adaptability of this header will take long time or may not take place in case the company provides better means for troubleshooting. 

In case of SIPREC, the multiple communication session has to be related together in a single recording session using the unique id. Most of the folks in SIPREC mailing alias thinks that session-id in communication session will serve the purpose. IMO, the usability of the session-id has to be extended and it has to be generic rather than specific service or application.

As I mentioned in the earlier mail thread with RE-INVITE based transfer in B2BUA usecase, session-id in the current form will not serve the purpose for troubleshooting as well. Cisco has the header similar to session-id which is named as "cisco-guid" which has the issue in handling the mentioned usecase. We need to find the better solution for session-id.

Thanks

Partha

________________________________

From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Wed 10/27/2010 7:35 PM
To: Parthasarathi R (partr)
Cc: Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [RAI] Minutes of 3GPP - IETF telco on the 19th of October

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Oct 2010 01:22:01 -0400

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,

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.

Thanks
Partha

Cc: Paul Kyzivat (pkyzivat); [email-masked]<mailto:[email-masked]>

-hadriel

On Oct 27, 2010, at 5:50 AM, Parthasarathi R (partr) wrote:

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat (pkyzivat)
> To: [email-masked]<mailto:[email-masked]>
>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>
>>>
>>>    Hi,
>>>    On Oct 22, 2010, at 9:32 AM, <[email-masked]<mailto:[email-masked]>
>>>    <mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>
>>>    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 28 Oct 2010 11:50:42 +0530

Hadriel,
 
I'm reading your mail like IETF has to add "n" number of correlation id
header based upon the usage.  we need to create the correlation id like
troubleshoot-id: xxxxx, recording-cs-id: xxxxxx individually. In case
everybody feels so, I'm fine with the approach.
 
Still, I'm not getting your concern w.r.t SIPREC correlation id and why
SIPREC session id will not be passed across in SIP devices but
trouble-shoot-id will? Please elaborate in this mail thread or in SIPREC
IETF alias.
 
In my experience with unique SIP session identification (cisco-guid),
the current proposed "session-id" will not work for number of 3PCC
callflows. In case you feel that troubleshoot id for 3PCC callflow has
to be based on another troubleshoot-id-part-2 ;-) Then it requires more
discussion in IETF.
 
Thanks
Partha

From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Thursday, October 28, 2010 10:52 AM
To: Parthasarathi R (partr)
Cc: Paul Kyzivat (pkyzivat); [email-masked];
[email-masked]
Subject: Re: [RAI] Minutes of 3GPP - IETF telco on the 19th of October

If you don't want to implement support for passing through a session-id
header, then don't.  No one's making you.  We're talking about an RFC,
not a Biblical commandment.  There are a boat-load of RFC's no one's
ever implemented.

It's not the be-all-end-all final solution for world hunger.  It's just
one header.  It's one tool in a bag of tools.

If some vendors support passing a session-id header and other's don't,
it won't be as useful as it could have been.  My customers tell me such
a header would help them.  Maybe I'm naive, but I would think when
customers tell their vendors to do something, the vendors generally try
to do it.  Especially if it's trivial to implement and helps the vendors
*themselves* with supporting the customers in TAC.  So my belief is the
market will decide if session-id succeeds - customers will either want
it, or not.  Meanwhile, all it takes to find out is to publish a fairly
simple RFC.  If it fails, we've wasted some IETF people's time and an
RFC number.  If it succeeds, we've made SIP a little bit easier to
manage, for all of us.

SIPCLF is orthogonal to session-id, really. In fact, one would hope the
session-id would be recorded in SIPCLF as well.  Had we published
session-id when it was initially proposed, it would have been available
in time for SIPCLF to make a mandatory field. 

As for SIPREC, that's exactly the problem: I already *know* of cases
where we'll need to remove whatever correlation id siprec ends up using.
Overloading this header for such things is just bound to reduce its
troubleshooting value, because we'll need to remove or change it.  But
that's *OK* - we have no shortage of header names available in SIP ABNF.
They can go define whatever new header-name they'd like, with another
value.

-hadriel

	
	
	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

	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:
	
	>>> I have implemented this as well. It has utility in a
non-trouble
	>>> shooting context in my application.
	>>>
	>>>>    please find the minutes of the 3GPP - IETF telco earlier
this
	> week.
	>>>>    *#*     *Old APs from previous meetings*
*Responsible*
	> *Status*
	>>>>    14      Talk with ECRIT chairs and Robert Sparks to make
a
	> proposal on
	>>>>    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
	>>>>    18      Decide between the editor, DISPATCH co-chairs
and AD the
	> best
	>>>>    Outside this meeting it has been agreed with ATOCA WG
chairs
	> that
	>>>>    being prepared in small expert group. The drafting group
does
	> not
	>>>>    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?
	>>>>    The 3GPP requirement is to identify special registration
for
	>>>>    emergency purposes.
	>>>>    it has been recently treated in DISPATCH but no firm
decision
	> was
	>>>>    Maastricht. The new version will be discussed in Beijing
IETF.
	> If
	>>>>    This draft has been in IESG for a while and it has got
stuck in
	> a
	>>>>    The editor is waiting for the comment from the AD
(Robert
	> Sparks).
	>>>>    There has been discussion on the 3GPP requirement for
this. Now
	> a
	>>>>    expect to be ready for WGLC after the Beijing meeting
(Nov
	> 2010),
	>>>>    This draft has got a patent issue related with
publication
	> number
	>>>>    text has been discussed but the group has not been
chartered
	> yet.
	>>>>    New version of draft-liess-dispatch-alert-info-urns has
been
	>>>>    distributed today.
	>>>>    The session matching draft
(draft-ietf-simple-msrp-sessmatch)
	> has
	>>>>    The status of draft-yu-tel-dai in the I-D tracker will
be
	> checked
	>>>>    draft-pkix-cmp-transport-protocols is also marked as
critical,
	>>>>    but no comments were made on it.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Oct 2010 09:52:18 +0200

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

> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: 28 October 2010 07:21
> To: Hadriel Kaplan
> Cc: Paul Kyzivat (pkyzivat); [email-masked]; Elwell, John
> Subject: RE: [RAI] Minutes of 3GPP - IETF telco on the 19th of October
>
> Hadriel,
>
> I'm reading your mail like IETF has to add "n" number of
> correlation id header based upon the usage.  we need to
> create the correlation id like troubleshoot-id: xxxxx,
> recording-cs-id: xxxxxx individually. In case everybody feels
> so, I'm fine with the approach.
>
> Still, I'm not getting your concern w.r.t SIPREC correlation
> id and why SIPREC session id will not be passed across in SIP
> devices but trouble-shoot-id will? Please elaborate in this
> mail thread or in SIPREC IETF alias.
>
> In my experience with unique SIP session identification
> (cisco-guid), the current proposed "session-id" will not work
> for number of 3PCC callflows. In case you feel that
> troubleshoot id for 3PCC callflow has to be based on another
> troubleshoot-id-part-2 ;-) Then it requires more discussion in IETF.
>
> Thanks
> Partha
>
>
> 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
>
>               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
>               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
>
>
>
>
>       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
>
>
>       > From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
>       > Paul Kyzivat (pkyzivat)
>       >>> I have implemented this as well. It has utility in
> a non-trouble
>       >>>>    please find the minutes of the 3GPP - IETF
> telco earlier this
>       > week.
>       >>>>    14      Talk with ECRIT chairs and Robert
> Sparks to make a
>       > proposal on
>       >>>>    15      Request for volunteers from 3GPP side
> to co-author
>       >>>>    16      Check with 3GPP LS officer why the LS
> C1-101810 was not
>       >>>>    18      Decide between the editor, DISPATCH
> co-chairs and AD the
>       > best
>       >>>>    Outside this meeting it has been agreed with
> ATOCA WG chairs
>       > that
>       >>>>    being prepared in small expert group. The
> drafting group does
>       > not
>       >>>>    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?
>       >>>>    The 3GPP requirement is to identify special
> registration for
>       >>>>    emergency purposes.
>       >>>>    it has been recently treated in DISPATCH but no
> firm decision
>       > was
>       >>>>    made on this yet.
>       >>>>    Maastricht. The new version will be discussed
> in Beijing IETF.
>       > If
>       >>>>    This draft has been in IESG for a while and it
> has got stuck in
>       > a
>       >>>>    The editor is waiting for the comment from the
> AD (Robert
>       > Sparks).
>       >>>>    There has been discussion on the 3GPP
> requirement for this. Now
>       > a
>       >>>>    expect to be ready for WGLC after the Beijing
> meeting (Nov
>       > 2010),
>       >>>>    text has been discussed but the group has not
> been chartered
>       > yet.
>       >>>>    New version of
> draft-liess-dispatch-alert-info-urns has been
>       >>>>    distributed today.
>       >>>>    The author of
> draft-jesske-dispatch-reason-in-responses would
>       >>>>    The status of draft-yu-tel-dai in the I-D
> tracker will be
>       > checked
>       >>>>    draft-pkix-cmp-transport-protocols is also
> marked as critical,

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 28 Oct 2010 05:03:18 -0400

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)
<[email-masked]>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
> In case of SIPREC, the multiple communication session has to be related
> together in a single recording session using the unique id. Most of
> the folks in SIPREC mailing alias thinks that session-id in communication
> session will serve the purpose. IMO, the usability of the session-id has to
> be extended and it has to be generic rather than specific service or
> application.
>
>
>
> As I mentioned in the earlier mail thread with RE-INVITE based transfer in
> B2BUA usecase, session-id in the current form will not serve the purpose for
> troubleshooting as well. Cisco has the header similar to session-id which
> is named as "cisco-guid" which has the issue in handling the mentioned
> usecase. We need to find the better solution for session-id.
>
>
>
> Thanks
>
> Partha
>
>
>
>
>  ------------------------------
>  *From:* Hadriel Kaplan [mailto:[email-masked]]
> *Sent:* Wed 10/27/2010 7:35 PM
> *To:* Parthasarathi R (partr)
> *Cc:* Paul Kyzivat (pkyzivat); [email-masked]
>
> *Subject:* Re: [RAI] Minutes of 3GPP - IETF telco on the 19th of October
>
>
> I'm not sure which way you mean this - do you mean if I don't get this
> published as an IETF RFC then SBC's will remove it, or do you mean even if
> we go define this as an IETF RFC SBC's will still remove it?
>
> I'm fairly confident that if it's published as an IETF RFC in its current
> form then SBC's won't remove it - or they will provide upgrades to not
> remove it.  I believe that because in my experience SBC's do what their
> owners/operators want them to do.  Whether specific operators/admins decide
> to have their SBCs remove it or not remains to be seen, but if it's useful
> for troubleshooting while not harmful then my guess is they'll want the
> session-id to be passed through.  IF it causes any call failures, then
> they'll block it, which is why I'm so concerned about expanding the scope of
> it to other things than troubleshooting.
>
> If it's not published as an IETF RFC, then its less likely to succeed in
> the marketplace.  I could just take it to 3gpp, but I was hoping to make
> this useful in non-IMS networks as well, such as Enterprise.
>
> -hadriel
>
>
> > From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of
> > Paul Kyzivat (pkyzivat)
> >>> <[email-masked] <mailto:[email-masked]<[email-masked]>>>
> wrote:
> >>>
> >>>
> >>>    Hi,
> >>>    <mailto:[email-masked] <[email-masked]>>> <
> [email-masked]
> >>>    <mailto:[email-masked] <[email-masked]>>>
> wrote:
> >>>
> >>>>    Dear all,
> >>>    [email-masked] <mailto:[email-masked] <[email-masked]>>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 28 Oct 2010 14:52:15 +0530

Peter,
 
I agree with you that it is better to correlate the related dialogs in
SIPCLF logs of a SIP device. This will be helpful particularly in B2BUA
troubleshooting.
 
Thanks
Partha

From: Peter Musgrave [mailto:[email-masked]] 
Sent: Thursday, October 28, 2010 2:33 PM
To: Parthasarathi R (partr)
Cc: Hadriel Kaplan; [email-masked]
Subject: Re: [RAI] Minutes of 3GPP - IETF telco on the 19th of October

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

<[email-masked]> wrote:

	Hadriel,

	Thanks

	Partha

	

	-hadriel

October
non-trouble
this
*Responsible*
a
co-author
was not
and AD the
chairs
does
AP 17
sponsored
for
decision
IETF.
stuck in
(Robert
this. Now
(Nov
publication
chartered
been
be
critical,

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 29 Oct 2010 14:00:45 -0400

Technically that isn't a "Catch-22", because using separate headers for every use would *work*, it's just an outcome we'd rather avoid. :)

I don't know if really requires a separate header for *each* purpose, just that troubleshooting *in particular* should be separate.
The reason is troubleshooting is one of those things that you want to work no matter what, and not affect/impact the signaling or call processing logic; you don't want any call processing logic behavioral changes tied to the stuff you're troubleshooting with - because you don't want to troubleshoot the troubleshooting info.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Oct 2010 17:15:38 -0400

> The reason is troubleshooting is one of those things that you want to work no matter what, and not affect/impact the signaling or call processing logic; you don't want any call processing logic beh…

Hmm. Interesting perspective.

It still seems to me that "troubleshooting" is too vague. By nailing 
down the dialogs that share the same session-id (as you must do), you 
immediately rule out using to to troubleshoot problems that require 
correlating a different set of things.

ISTM that this is an identifier for those sets of dialogs that are 
correlated based on the rules in the draft for reusing the id in 
multiple dialogs.

Once that is defined, it should be equally appropriate to use it for any 
purpose for which it is appropriately defined. And clearly you can't 
stop that from happening even if you want to.

The Catch-22 is that it will work if B2BUAs are motivated to support it 
and think it not a risk that must be "fixed" by blocking the header. But 
if somebody finds another use for this header that is eventually 
determined to be a risk by somebody, then they may block the header to 
block that risk.

Of course I find that behavior to be ill-conceived. But I also consider 
blocking pretty much anything in an SBC to be ill-conceived. Obviously 
I'm in the minority. (I'm pretty much a libertarian or anarchist when it 
comes to internet police.)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 29 Oct 2010 18:40:00 -0400

> correlating a different set of things.

It doesn't "rule them out" - it just doesn't solve those troubleshooting desires.  For example, one obvious desire would be to troubleshoot a conference call, by getting all messages for participants to a conf server.  Session-id won't do it.  But that's *ok*.  It helps us solve more problems (or solve them more easily) than today.  It doesn't solve all possible/imaginable troubleshooting correlation scenarios, but I'd argue getting a vast majority of the cases isn't a bad thing.

> stop that from happening even if you want to.

Yup.  That's the part that concerns me.  It's just so tempting to re-use it for other matching properties.  But there's really nothing anyone can do to stop that - the draft pleads/warns people not to, which is about all that can be done.

> comes to internet police.)

The cases I can imagine a session-id would be "blocked" for aren't evil ones, nor due to "risks".  When I look at what people remove today, it's either due to privacy concerns or to actually make things *work* right.  

The former case is obvious, and even with session-id it's possible that someone considers it a privacy risk because it provides a way to trace a call back to the originator even it went through an anonymization service, if that anonymization service passes on the session-id. (I don't mean a "privacy" service for user privacy, but an anonymization service that wants to provide fully untraceable calls such that even the government couldn't trace it)  But I'm not worried about that case - they'll strip session-id, and they should.  Other than that, though, the current session-id proposal shouldn't raise any privacy concerns, afaik.

The latter rationale for removing headers (to make stuff work), is where I think session-id could be removed by an SBC and negatively impact troubleshooting.  SBCs remove headers for this reason all the time.  Sometimes it's because some downstream element can't handle unknown headers (it still shocks me how many systems continue to have this behavior), but half the time it's because some downstream element isn't processing stuff correctly because it *does* know the header, but either has a bug or its use of the header creates unwanted side-effects. 

So for example, suppose you use session-id for loop detection on sip trunks.  If you get the same session-id more than once you decide it's a loop and reject the request.  But you forgot to handle legitimate spiral cases, or you decided to allow it more than once but limited it to appearing twice and someone has a call flow where it can spiral 3 times, or 4, or whatever.  One would think that that's your bug and you should fix it, but often it's easier for your customer to just have the SBC remove the session-id and avoid the bug.  

Or suppose you use session-id for forking detection.  If you get the same session-id from the same side of a trunk you decide it's a forking case so you don't do multiple CAC reservations.  Meanwhile, unbeknownst to you an upstream device isn't forking a single call request but in fact doing a cron-conference or broadcast announcement, and happens to use the same session-id value because it helps troubleshooting.  Once again, removing the session-id "fixes" it.

Or suppose you use session-id for SIPREC.  If the recording server sees the same session-id for two different recording sessions, it either correlates them in its analytics, or even only records one of the sessions.  But in some cases the two calls really do need to be recorded separately, or must not be correlated in analytics - this can happen if the recorder isn't smart enough to have specific policies about when it should or should not do such correlation.  Once again, removing the session-id "fixes" it.

Or suppose you use session-id for per-use licensing or call constraints, such that you count two calls of the same session-id as one call from an RTU/limits perspective.  Then someone finds out about it, posts about it on the web, and people start using the same session-id for all calls to avoid the restriction.  That won't help troubleshooting either. 

-hadriel