Subject: Re: [dispatch] Session-ID charter proposal

From: [email-masked]
Date: Mon, 10 May 2010 21:12:10 +0800

Hi,

Please let me make my question clearly. Considering 
billing/charging/policy and LI(lawful interception), there's use cases of 
correlating "session" and "message-flow". In fact, we have done 
billing/charging/policy and LI without such new header. So, I said that I 
did not find requirement of defining new header to correlate "session" and 
"message-flow".

Maybe there's use case and requirement for the new header. So, I'd like to 
see it's detail.

Thanks,

Gao 

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================
----- 转发人 GaoYang140197/user/zte_ltd 时间 2010-05-10 21:02 -----

GaoYang140197/user/zte_ltd
2010-05-10 20:56

收件人
Hadriel Kaplan <[email-masked]>
抄送
DISPATCH <[email-masked]>, [email-masked]
主题
Re: [dispatch] Session-ID charter proposal

Hi,

I'd like to see the requirement of the header and typical use case for it 
in the charter.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Hadriel Kaplan <[email-masked]> 
发件人:  [email-masked]
2010-05-09 04:35

收件人
DISPATCH <[email-masked]>
抄送

主题
[dispatch] Session-ID charter proposal

Howdy,
I have asked the DISPATCH chairs what to do with Session-ID, given the 
feedback I received to make it a standards-track vs. individual 
informational submission.  There is no obvious current WG for this work, 
so they asked me to post a strawman charter proposal, which I propose as 
follows:

SIP Signaling-COmmunication Troubleshooting with Correlation Header 
(SIPSCOTCH) Charter:
----------------------------------
The SIPSCOTCH working group is chartered to define a mechanism that allows 
operators and monitoring equipment to correlate SIP messages and dialogs 
of the same higher-level end-to-end "session" or "message-flow".  In 
particular, the mechanism must be able to allow such correlation across 
SIP B2BUAs of as many functional types as possible, such as Application 
Servers, Softswitches, PBXs, SBCs, etc.

Although other solutions may be possible, this working group will focus on 
defining a new SIP Header field for such a purpose, similar to the Call-ID 
header field, in order to provide a simple, easily deployable mechanism 
which can work across SIP domains. The SIP Call-ID header field value 
itself is not usable for such correlation, because many B2BUAs must create 
a new Call-ID value on their UAC "side" in order to function properly, and 
to comply with the rules of RFC 3261. 

It should be noted that certain SIP B2BUAs perform a "topology-hiding" 
function, as described in RFC 5853.  The working group will take such 
functions into account for the correlation mechanism, as well as provide 
guidance for implementers of the mechanism to avoid triggering such a 
function for the mechanism's header field value.

Lastly, although in certain environments such a mechanism may be usable 
for dialog correlation in SIP state machines, it is not the goal of this 
working group to address that usage.

Goals and Milestones
====================
Dec 2010 - New header specification to IESG (PS)

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 May 2010 12:33:51 -0400

The purpose is for troubleshooting, across multiple systems.  I had that in the title of the charter, but you’re right I forgot to explicitly call that out in the charter.
How about this new first sentence:
The SIPSCOTCH working group is chartered to define a mechanism that allows operators and monitoring equipment to correlate SIP messages and dialogs of the same higher-level end-to-end "session" or "message-flow" across multiple SIP devices, for the purpose of troubleshooting.

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 10, 2010 9:12 AM
To: Hadriel Kaplan
Cc: DISPATCH
Subject: Re: [dispatch] Session-ID charter proposal

Hi,

Please let me make my question clearly. Considering billing/charging/policy and LI(lawful interception), there's use cases of correlating "session" and "message-flow". In fact, we have done billing/charging/policy and LI without such new header. So, I said that I did not find requirement of defining new header to correlate "session" and "message-flow".

Maybe there's use case and requirement for the new header. So, I'd like to see it's detail.

Thanks,

Gao

----- 转发人 GaoYang140197/user/zte_ltd 时间 2010-05-10 21:02 -----

2010-05-10 20:56

收件人

抄送

主题

Re: [dispatch] Session-ID charter proposal链接<Notes://NJMAIL01/48257169002DF8EE/DABA975B9FB113EB852564B5001283EA/79A70615A2D6AE194825771D00711D78>

Hi,

I'd like to see the requirement of the header and typical use case for it in the charter.

Thanks,

Gao

2010-05-09 04:35

收件人

抄送

主题

Howdy,
I have asked the DISPATCH chairs what to do with Session-ID, given the feedback I received to make it a standards-track vs. individual informational submission.  There is no obvious current WG for this work, so they asked me to post a strawman charter proposal, which I propose as follows:

SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCOTCH) Charter:
----------------------------------
The SIPSCOTCH working group is chartered to define a mechanism that allows operators and monitoring equipment to correlate SIP messages and dialogs of the same higher-level end-to-end "session" or "message-flow".  In particular, the mechanism must be able to allow such correlation across SIP B2BUAs of as many functional types as possible, such as Application Servers, Softswitches, PBXs, SBCs, etc.

Although other solutions may be possible, this working group will focus on defining a new SIP Header field for such a purpose, similar to the Call-ID header field, in order to provide a simple, easily deployable mechanism which can work across SIP domains. The SIP Call-ID header field value itself is not usable for such correlation, because many B2BUAs must create a new Call-ID value on their UAC "side" in order to function properly, and to comply with the rules of RFC 3261.

It should be noted that certain SIP B2BUAs perform a "topology-hiding" function, as described in RFC 5853.  The working group will take such functions into account for the correlation mechanism, as well as provide guidance for implementers of the mechanism to avoid triggering such a function for the mechanism's header field value.

Lastly, although in certain environments such a mechanism may be usable for dialog correlation in SIP state machines, it is not the goal of this working group to address that usage.

Goals and Milestones
====================

---

From: [email-masked]
Date: Tue, 11 May 2010 09:16:35 +0800

Hi,

My means is, in the any point of the traverse of the sip dialog, we can 
identify the correlation. And at different points on the two sides of 
B2BUA equipment(such as AS), we can figure out the correlation by the 
mapping/correlation by the B2BUA equipment.

Considering the new header, if the B2BUA equipment just expurgate the 
header from one side's dialog to another, would it be a problem for the 
correlation?

My questions may be too early. Maybe you can answer it at the draft stage.

Thanks,

Gao

2010-05-11 00:33

收件人
"[email-masked]" <[email-masked]>
抄送
DISPATCH <[email-masked]>
主题
RE: [dispatch] Session-ID charter proposal

The purpose is for troubleshooting, across multiple systems.  I had that 
in the title of the charter, but you’re right I forgot to explicitly call 
that out in the charter.
How about this new first sentence:
The SIPSCOTCH working group is chartered to define a mechanism that allows 
operators and monitoring equipment to correlate SIP messages and dialogs 
of the same higher-level end-to-end "session" or "message-flow" across 
multiple SIP devices, for the purpose of troubleshooting.
 
-hadriel

Hi, 

Thanks, 

Gao   

----- 转发人 GaoYang140197/user/zte_ltd 时间 2010-05-10 21:02 ----- 

收件人
Hadriel Kaplan <[email-masked]> 
抄送
DISPATCH <[email-masked]>, [email-masked] 
主题
Re: [dispatch] Session-ID charter proposal链接

Hi, 

Thanks, 

Gao 

收件人
 
主题

Howdy,

Goals and Milestones
====================

 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 May 2010 23:58:55 -0400

No B2BUA has to support any new RFC.  Assuming the WG decides on a new header “Foobar” for the mechanism, and published an RFC XYZ saying B2BUA’s must pass “Foobar” through, then a B2BUA does not have to pass it through – it just wouldn’t be implementing or be compliant with RFC XYZ if it didn’t.  But if the B2BUA claimed compliance with RFC XYZ, then it would have to follow the RFC and pass “Foobar” when it’s set to – it could not expurgate the header if it claimed to implement the RFC.  If operators want this thing, then they’ll tell their vendors to do RFC XYZ.

I’m not sure if that was your question/comment though.  Maybe you just mean “we don’t need this”.  That’s fine, then you don’t need it.  Many if not all B2BUA vendors have means of correlating messages, whether it be in proprietary headers, “special” info in Call-IDs, or just logs or even CDRs.  And a few monitoring vendors have figured out how to correlate the messages when they cross through B2BUA’s too, or will collect the logs specifically to do so.  That’s all fine, and nobody’s stopping them.  We’re just providing a mechanism to let people do it more simply, in a consistent fashion, without having to go through all that.

I know it’s hard to justify implementing this thing when you already have a way to correlate it yourself, or if your favorite monitoring vendors have already figured out how to.  I’ve had that same problem arguing for it in my own company, because we too have different ways of doing it already.  But if we want SIP to be deployed faster and cost less in opex, we have to help operators manage and troubleshoot as easily as possible.  This WG is for just one small piece, but it’s also not that much work for B2BUA vendors I would think/hope.

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 10, 2010 9:17 PM
To: Hadriel Kaplan
Cc: DISPATCH
Subject: RE: [dispatch] Session-ID charter proposal

Hi,

My means is, in the any point of the traverse of the sip dialog, we can identify the correlation. And at different points on the two sides of B2BUA equipment(such as AS), we can figure out the correlation by the mapping/correlation by the B2BUA equipment.

Considering the new header, if the B2BUA equipment just expurgate the header from one side's dialog to another, would it be a problem for the correlation?

Thanks,

Gao

2010-05-11 00:33

收件人

抄送

主题

-hadriel

Hi,

Thanks,

Gao

----- 转发人 GaoYang140197/user/zte_ltd 时间 2010-05-10 21:02 -----

2010-05-10 20:56

收件人

抄送

主题

Re: [dispatch] Session-ID charter proposal链接<Notes://njmail01/48257169002DF8EE/DABA975B9FB113EB852564B5001283EA/79A70615A2D6AE194825771D00711D78>

Hi,

Thanks,

Gao

2010-05-09 04:35

收件人

抄送

主题

Howdy,

Goals and Milestones
====================

---

From: [email-masked]
Date: Tue, 11 May 2010 13:18:06 +0800

> I’m not sure if that was your question/comment though.  Maybe you 
> just mean “we don’t need this”.  That’s fine, then you don’t need 
> it. 

I am not trying to say "we don't need this". I just want to ask why we 
need the header?
I didn't want to stop your process. Just want to get a more convictive 
background for this new header. So, I said, a antitheses might be needed.

>Many if not all B2BUA vendors have means of correlating 
> messages, whether it be in proprietary headers, “special” info in 
> Call-IDs, or just logs or even CDRs.  And a few monitoring vendors 
> have figured out how to correlate the messages when they cross 
> through B2BUA’s too, or will collect the logs specifically to do so.

Considering there's one B2BUA AS in the network, and it doesn't support 
this header. What would happen? And if the B2BUA AS has been deployed in 
the network before the LI/monitoring equipment, how can the LI/monitoring 
equipment's people demand the supporting of the new header for the 
*blocking* B2BUA AS?

I'd like to emphasize that LI thing is not optional like one servie level 
extension. So, as the original requirement is from LI/monitoring aspect, 
the interworking and compatibility issue might be more than optional 
supporting one potential RFC.

> That’s all fine, and nobody’s stopping them.  We’re just providing a
> mechanism to let people do it more simply, in a consistent fashion, 
> without having to go through all that.

Yes. As I think mechanism's defintion is one issue, it's interworking and 
compatibility is another issue.

So, I'd like to emphasize that I am OK with your charter as I said. But I 
am not sure about interworking and compatibility of the new header. 

Thanks,

Gao