Subject: [dispatch] Proposal for Session ID charter

From: Cullen Jennings <[email-masked]>
Date: Thu, 29 Jul 2010 18:30:18 +0200

I tried to write a proposal that I think reflects what the proponents of this WG want. Here's my stab at it. 

------------------

Troubleshooting SIP networks can be improved by correlating messaging across several devices. This working group will define a correlation identifier to be used for the troubleshooting and the for correlation of logging information from different SIP devices in the network. 

Sip transactions are often triggered by another SIP transaction. Two transactions are in the same "session" if one was triggered by the other due to redirection, REFER processing, retargeting, or forwarding on a B2BUA. This working group will define a correlation identifier that identifies  all the transactions in the same session.  The scope of the identifier pertains to the SIP signaling layer only, and not media.   For example, several UA participating in a conference call may be receiving the same media but would not be in the same session. 

The design of the correlation identifier needs to take into account the issue of not revealing the topology of network. The mechanism should be applicable for Proxies, UAs, PBXs, SBCs, Application Servers, Softswitches, Phones, and Gateways. 

This working group will coordinate with other relevant working groups and area including Ops, and sipcore.

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 29 Jul 2010 20:18:58 +0200

I think this is fine.

Peter Musgrave

On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings <[email-masked]> wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Jul 2010 14:35:05 -0400

Looks fine to me.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cullen Jennings
> Sent: Thursday, July 29, 2010 12:30 PM
> To: [email-masked] list
> Subject: [dispatch] Proposal for Session ID charter
> 
> 
> Troubleshooting SIP networks can be improved by correlating messaging
> across several devices. This working group will define a correlation
> identifier to be used for the troubleshooting and the for correlation of
> logging information from different SIP devices in the network.
> 
> Sip transactions are often triggered by another SIP transaction. Two
> transactions are in the same "session" if one was triggered by the other
> due to redirection, REFER processing, retargeting, or forwarding on a
> B2BUA. This working group will define a correlation identifier that
> identifies  all the transactions in the same session.  The scope of the
> identifier pertains to the SIP signaling layer only, and not media.   For
> example, several UA participating in a conference call may be receiving
> the same media but would not be in the same session.
> 
> The design of the correlation identifier needs to take into account the
> issue of not revealing the topology of network. The mechanism should be
> applicable for Proxies, UAs, PBXs, SBCs, Application Servers, Softswitches,
> Phones, and Gateways.
>

---

From: Laura Liess <[email-masked]>
Date: Thu, 29 Jul 2010 22:19:42 +0200

It works for me.
Laura

---

From: Victor Pascual Avila <[email-masked]>
Date: Fri, 30 Jul 2010 00:49:37 +0200

I like it

-- 
Victor Pascual Ávila

---

From: [email-masked]
Date: Fri, 30 Jul 2010 08:37:18 +0800

Hi Cullen,

I am fine with this one, as there's no explicit demand for UPDATEing 
RFC3891.

Thanks,

Gao

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

Cullen Jennings <[email-masked]> 
发件人:  [email-masked]
2010-07-30 00:30

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

主题
[dispatch] Proposal for Session ID charter

I tried to write a proposal that I think reflects what the proponents of 
this WG want. Here's my stab at it. 

------------------

The design of the correlation identifier needs to take into account the 
issue of not revealing the topology of network. The mechanism should be 
applicable for Proxies, UAs, PBXs, SBCs, Application Servers, 
Softswitches, Phones, and Gateways. 

This working group will coordinate with other relevant working groups and 
area including Ops, and sipcore. 

--------------------------------------------------------
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: "Elwell, John" <[email-masked]>
Date: Fri, 30 Jul 2010 09:46:27 +0200

Can somebody please remind me why this is scoped only for troubleshooting. For example, in SIPREC, we anticipate a need for a Session Recording Server to be able to correlate two recorded sessions from different Session Recording Clients. For example, if a customer call is transferred from one agent to a second agent, the two agents might be using different Session Recording Clients to send media to the Session Recording Server. What would be the barrier to using session ID for this case? Is it just the lack of guaranteed uniqueness, or are there other factors?

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Victor Pascual Avila
> Sent: 29 July 2010 23:50
> To: Cullen Jennings
> Cc: [email-masked] list
> Subject: Re: [dispatch] Proposal for Session ID charter
> 
> I like it
> 
> > I tried to write a proposal that I think reflects what the 
> proponents of this WG want. Here's my stab at it.
> >
> > ------------------
> >
> >
> > Troubleshooting SIP networks can be improved by correlating 
> messaging across several devices. This working group will 
> define a correlation identifier to be used for the 
> troubleshooting and the for correlation of logging 
> information from different SIP devices in the network.
> >
> > Sip transactions are often triggered by another SIP 
> transaction. Two transactions are in the same "session" if 
> one was triggered by the other due to redirection, REFER 
> processing, retargeting, or forwarding on a B2BUA. This 
> working group will define a correlation identifier that 
> identifies  all the transactions in the same session.  The 
> scope of the identifier pertains to the SIP signaling layer 
> only, and not media.   For example, several UA participating 
> in a conference call may be receiving the same media but 
> would not be in the same session.
> >
> > The design of the correlation identifier needs to take into 
> account the issue of not revealing the topology of network. 
> The mechanism should be applicable for Proxies, UAs, PBXs, 
> SBCs, Application Servers, Softswitches, Phones, and Gateways.
> >
> > This working group will coordinate with other relevant 
> working groups and area including Ops, and sipcore.
> >
> >
> >
> >
> >
> >

---

From: <[email-masked]>
Date: Fri, 30 Jul 2010 10:13:29 +0200

Hi Cullen,
Thank you for your proposal.

I'm fine with it  

Best Regards

Roland
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Cullen Jennings
Gesendet: Donnerstag, 29. Juli 2010 18:30
An: [email-masked] list
Betreff: [dispatch] Proposal for Session ID charter

------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Jul 2010 04:21:29 -0400

Elwell, John wrote:
> Can somebody please remind me why this is scoped only for troubleshooting.

Yeah. This seems to be "that which shall not be spoken".

It seems clear that people intend to use this for more than 
troubleshooting, or else have very broad definitions of what 
troubleshooting is.

ISTM its would be good to have a number of intended uses, so long as 
they are compatible - can use the same correlation algorithm.

OTOH, opening it up that way could lead to a food fight and different 
uses fight to get a correlation function that meets their needs.

	Thanks,
	Paul

> For example, in SIPREC, we anticipate a need for a Session Recording Server to be able to correlate two recorded sessions from different Session Recording Clients. For example, if a customer call is transferred from one agent to a second agent, the two agents might be using different Session Recording Clients to send media to the Session Recording Server. What would be the barrier to using session ID for this case? Is it just the lack of guaranteed uniqueness, or are there other factors?
> 
> John
>  
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 30 Jul 2010 10:33:25 +0200

What I was thinking was that it could be used for other purposes "at your own risk". However, if we tried to get this into some other RFC (e.g., if SIPREC were to need it for correlating two sessions at a session recording server), we might get pushback if the session-ID RFC limits its scope to troubleshooting. I wouldn't want to go through the effort of specifying yet another header field whenever some other usage arises.

The trick seems to be to make session-ID sufficiently general purpose without introducing any disincentive for B2BUA implementers and deployers to use it correctly.

John

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 30 July 2010 09:21
> To: Elwell, John
> Cc: Cullen Jennings; [email-masked] list
> > For example, in SIPREC, we anticipate a need for a Session 
> Recording Server to be able to correlate two recorded 
> sessions from different Session Recording Clients. For 
> example, if a customer call is transferred from one agent to 
> a second agent, the two agents might be using different 
> Session Recording Clients to send media to the Session 
> Recording Server. What would be the barrier to using session 
> ID for this case? Is it just the lack of guaranteed 
> uniqueness, or are there other factors?
> > 
> > John
> >  
> >

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 30 Jul 2010 10:34:16 +0200

Hi,

IIRC the question Robert Sparks asked at dispatch was part of this.

RS: "Does anyone think this provides dialog correlation? It doesn't"

I think the issue was that an INVITE which forks and is answered by
two parties will have the same SessionID used for what could be viewed
as separate logical sessions.

In practice - I would expect one branch to get dropped - but it might
cause some heartburn in some non-troubleshooting applications of
session-ID. Hence the scope appears to be constructed to exclude cases
like this. I agree people may use it for more than the defined scope -
but the charter is designed to ensure people do this at their own risk
and to avoid the debate which other scopes would engender.

Peter Musgrave

On Fri, Jul 30, 2010 at 10:21 AM, Paul Kyzivat <[email-masked]> wrote:
> It seems clear that people intend to use this for more than troubleshooting,
> or else have very broad definitions of what troubleshooting is.
>
> ISTM its would be good to have a number of intended uses, so long as they
> are compatible - can use the same correlation algorithm.
>
> OTOH, opening it up that way could lead to a food fight and different uses
> fight to get a correlation function that meets their needs.
>
>        Thanks,
>        Paul
>
>> For example, in SIPREC, we anticipate a need for a Session Recording
>> Server to be able to correlate two recorded sessions from different Session
>> Recording Clients. For example, if a customer call is transferred from one
>> agent to a second agent, the two agents might be using different Session
>> Recording Clients to send media to the Session Recording Server. What would
>> be the barrier to using session ID for this case? Is it just the lack of
>> guaranteed uniqueness, or are there other factors?
>>
>> John
>>
>>>
>>> Behalf Of Victor Pascual Avila
>>> Sent: 29 July 2010 23:50
>>> To: Cullen Jennings
>>> messaging across several devices. This working group will define a
>>> correlation identifier to be used for the troubleshooting and the for
>>> correlation of logging information from different SIP devices in the
>>> network.
>>>>
>>> transaction. Two transactions are in the same "session" if one was
>>> triggered by the other due to redirection, REFER processing, retargeting, or
>>> forwarding on a B2BUA. This working group will define a correlation
>>> identifier that identifies  all the transactions in the same session.  The
>>> scope of the identifier pertains to the SIP signaling layer only, and not
>>> media.   For example, several UA participating in a conference call may be
>>> receiving the same media but would not be in the same session.
>>>>
>>> account the issue of not revealing the topology of network. The mechanism
>>> should be applicable for Proxies, UAs, PBXs, SBCs, Application Servers,

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 30 Jul 2010 10:43:15 +0200

If folks want to use it for something other than troubleshooting, now would be the time to talk about that. The charter proposal in this thread will most likely end up with producing an RFC that is not useful for much other than troubleshooting. For example, given the way session is defined here, it does not seem like it would work for SIPREC. 

>>>> working groups and area including Ops, and sipcore.

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 30 Jul 2010 14:34:27 +0530

If the correlation-id can identify its usage, I don't see why there would be a food fight. It seems logical for this WG to have an achievable goal and limit its work to the 'troubleshooting' usage, and define the rules for passing this id between different SIP entities it intends to troubleshoot. However, I don't see why we should stop another WG from defining an entirely different usage of this correlation-id. 

One way of conveying this usage is using a header parameter, so the rules defined by this WG would apply when this parameter specifies 'troubleshooting', which could even be the default usage when one isn't specified. However, the rules for constructing this correlation-id in such a way that it doesn't conflict with the policy functions, such as topology hiding in B2BUAs/SBCs, could remain common to all usages.

This seems analogous to STUN -- a tool than can have many usages.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf
|Of Paul Kyzivat (pkyzivat)
|Sent: Friday, July 30, 2010 1:51 PM
|To: Elwell, John
|Cc: [email-masked] list
|Subject: Re: [dispatch] Proposal for Session ID charter
|
|Elwell, John wrote:
|> Can somebody please remind me why this is scoped only for troubleshooting.
|
|Yeah. This seems to be "that which shall not be spoken".
|
|It seems clear that people intend to use this for more than
|troubleshooting, or else have very broad definitions of what
|troubleshooting is.
|
|ISTM its would be good to have a number of intended uses, so long as
|they are compatible - can use the same correlation algorithm.
|
|OTOH, opening it up that way could lead to a food fight and different
|uses fight to get a correlation function that meets their needs.
|
|	Thanks,
|	Paul
|
|> For example, in SIPREC, we anticipate a need for a Session Recording
|Server to be able to correlate two recorded sessions from different Session
|Recording Clients. For example, if a customer call is transferred from one
|agent to a second agent, the two agents might be using different Session
|Recording Clients to send media to the Session Recording Server. What would
|be the barrier to using session ID for this case? Is it just the lack of
|guaranteed uniqueness, or are there other factors?
|>
|> John
|>
|>
|>> -----Original Message-----
|>> From: [email-masked]
|>> [mailto:[email-masked]] On Behalf Of Victor Pascual Avila
|>> Sent: 29 July 2010 23:50
|>> To: Cullen Jennings
|>> Cc: [email-masked] list
|>> Subject: Re: [dispatch] Proposal for Session ID charter
|>>
|>> I like it
|>>
|>> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings
|>> <[email-masked]> wrote:
|>>> I tried to write a proposal that I think reflects what the
|>> proponents of this WG want. Here's my stab at it.
|>>> ------------------
|>>>
|>>>
|>>> Troubleshooting SIP networks can be improved by correlating
|>> messaging across several devices. This working group will
|>> define a correlation identifier to be used for the
|>> troubleshooting and the for correlation of logging
|>> information from different SIP devices in the network.
|>>> Sip transactions are often triggered by another SIP
|>> transaction. Two transactions are in the same "session" if
|>> one was triggered by the other due to redirection, REFER
|>> processing, retargeting, or forwarding on a B2BUA. This
|>> working group will define a correlation identifier that
|>> identifies  all the transactions in the same session.  The
|>> scope of the identifier pertains to the SIP signaling layer
|>> only, and not media.   For example, several UA participating
|>> in a conference call may be receiving the same media but
|>> would not be in the same session.
|>>> The design of the correlation identifier needs to take into
|>> account the issue of not revealing the topology of network.
|>> The mechanism should be applicable for Proxies, UAs, PBXs,
|>> SBCs, Application Servers, Softswitches, Phones, and Gateways.
|>>> This working group will coordinate with other relevant
|>> working groups and area including Ops, and sipcore.
|>>>
|>>>
|>>>
|>>>
|>>>
|>>> _______________________________________________
|>>> dispatch mailing list
|>>> [email-masked]
|>>> https://www.ietf.org/mailman/listinfo/dispatch
|>>>
|>>
|>>
|>> --
|>> Victor Pascual Ávila
|>> _______________________________________________
|>> dispatch mailing list
|>> [email-masked]
|>> https://www.ietf.org/mailman/listinfo/dispatch
|>>
|> _______________________________________________
|> dispatch mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/dispatch
|>
|_______________________________________________
|dispatch mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 30 Jul 2010 11:23:25 +0200

I think it is highly likely that correlating messages across several devices (I.e. two sides of a B2BUA) is going to be useful for more than just troubleshooting and agree that will be tool that can have many usages.

However the originator of the identifier cannot be expected to know what it is going to be used for so having an parameter specifying the usage does not make sense to me.

One example of how this might be useful to SIPREC is that it could be used to enable the recording system to identify that it recording the same session by two different recording clients. 

I would like to see the charter for the session ID working group being less specific about the usage and the solution to allow the WG to formulate the use cases and associated requirements. Maybe this may result in more work for the WG but that would be better than having multiple solutions for essentially the same problem.

Regards
Andy

> [mailto:[email-masked]] On Behalf Of Muthu 
> ArulMozhi Perumal (mperumal)
> Sent: 30 July 2010 11:04
> To: Paul Kyzivat (pkyzivat); Elwell, John
> Cc: [email-masked]
> If the correlation-id can identify its usage, I don't see why 
> there would be a food fight. It seems logical for this WG to 
> have an achievable goal and limit its work to the 
> 'troubleshooting' usage, and define the rules for passing 
> this id between different SIP entities it intends to 
> troubleshoot. However, I don't see why we should stop another 
> WG from defining an entirely different usage of this correlation-id. 
> 
> One way of conveying this usage is using a header parameter, 
> so the rules defined by this WG would apply when this 
> parameter specifies 'troubleshooting', which could even be 
> the default usage when one isn't specified. However, the 
> rules for constructing this correlation-id in such a way that 
> it doesn't conflict with the policy functions, such as 
> topology hiding in B2BUAs/SBCs, could remain common to all usages.
> 
> |From: [email-masked] 
> [mailto:[email-masked]] On Behalf

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 30 Jul 2010 15:13:02 +0530

|However the originator of the identifier cannot be expected to know
|what it is going to be used for

Two possible approaches:
1. Use different ids for different usages, so an intermediary would insert a new id at the point from which a new type of correlation is required.
2. Allow an intermediary to add another usage and then define the set of rules that should be applied when two or more usages are specified.

|I would like to see the charter for the session ID working group 
|being less specific about the usage and the solution to allow the
|WG to formulate the use cases and associated requirements.

Sure, but considering the fact that people can come up with numerous usages of this correlation-id, it seems this WG might find it difficult to freeze on a limited set of them.

Muthu

|-----Original Message-----
|From: Hutton, Andrew [mailto:[email-masked]]
|Sent: Friday, July 30, 2010 2:53 PM
|To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); Elwell,
|John
|Cc: [email-masked]
|Subject: RE: [dispatch] Proposal for Session ID charter
|
|
|I think it is highly likely that correlating messages across several devices
|(I.e. two sides of a B2BUA) is going to be useful for more than just
|troubleshooting and agree that will be tool that can have many usages.
|
|However the originator of the identifier cannot be expected to know what it
|is going to be used for so having an parameter specifying the usage does not
|make sense to me.
|
|One example of how this might be useful to SIPREC is that it could be used
|to enable the recording system to identify that it recording the same
|session by two different recording clients.
|
|I would like to see the charter for the session ID working group being less
|specific about the usage and the solution to allow the WG to formulate the
|use cases and associated requirements. Maybe this may result in more work
|for the WG but that would be better than having multiple solutions for
|essentially the same problem.
|
|Regards
|Andy
|
|
|
|> -----Original Message-----
|> From: [email-masked]
|> [mailto:[email-masked]] On Behalf Of Muthu
|> ArulMozhi Perumal (mperumal)
|> Sent: 30 July 2010 11:04
|> To: Paul Kyzivat (pkyzivat); Elwell, John
|> Cc: [email-masked]
|> Subject: Re: [dispatch] Proposal for Session ID charter
|>
|> If the correlation-id can identify its usage, I don't see why
|> there would be a food fight. It seems logical for this WG to
|> have an achievable goal and limit its work to the
|> 'troubleshooting' usage, and define the rules for passing
|> this id between different SIP entities it intends to
|> troubleshoot. However, I don't see why we should stop another
|> WG from defining an entirely different usage of this correlation-id.
|>
|> One way of conveying this usage is using a header parameter,
|> so the rules defined by this WG would apply when this
|> parameter specifies 'troubleshooting', which could even be
|> the default usage when one isn't specified. However, the
|> rules for constructing this correlation-id in such a way that
|> it doesn't conflict with the policy functions, such as
|> topology hiding in B2BUAs/SBCs, could remain common to all usages.
|>
|> This seems analogous to STUN -- a tool than can have many usages.
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: [email-masked]
|> [mailto:[email-masked]] On Behalf
|> |Of Paul Kyzivat (pkyzivat)
|> |Sent: Friday, July 30, 2010 1:51 PM
|> |To: Elwell, John
|> |Cc: [email-masked] list
|> |Subject: Re: [dispatch] Proposal for Session ID charter
|> |
|> |Elwell, John wrote:
|> |> Can somebody please remind me why this is scoped only for
|> troubleshooting.
|> |
|> |Yeah. This seems to be "that which shall not be spoken".
|> |
|> |It seems clear that people intend to use this for more than
|> |troubleshooting, or else have very broad definitions of what
|> |troubleshooting is.
|> |
|> |ISTM its would be good to have a number of intended uses, so long as
|> |they are compatible - can use the same correlation algorithm.
|> |
|> |OTOH, opening it up that way could lead to a food fight and different
|> |uses fight to get a correlation function that meets their needs.
|> |
|> |	Thanks,
|> |	Paul
|> |
|> |> For example, in SIPREC, we anticipate a need for a Session
|> Recording
|> |Server to be able to correlate two recorded sessions from
|> different Session
|> |Recording Clients. For example, if a customer call is
|> transferred from one
|> |agent to a second agent, the two agents might be using
|> different Session
|> |Recording Clients to send media to the Session Recording
|> Server. What would
|> |be the barrier to using session ID for this case? Is it just
|> the lack of
|> |guaranteed uniqueness, or are there other factors?
|> |>
|> |> John
|> |>
|> |>
|> |>> -----Original Message-----
|> |>> From: [email-masked]
|> |>> [mailto:[email-masked]] On Behalf Of Victor
|> Pascual Avila
|> |>> Sent: 29 July 2010 23:50
|> |>> To: Cullen Jennings
|> |>> Cc: [email-masked] list
|> |>> Subject: Re: [dispatch] Proposal for Session ID charter
|> |>>
|> |>> I like it
|> |>>
|> |>> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings
|> |>> <[email-masked]> wrote:
|> |>>> I tried to write a proposal that I think reflects what the
|> |>> proponents of this WG want. Here's my stab at it.
|> |>>> ------------------
|> |>>>
|> |>>>
|> |>>> Troubleshooting SIP networks can be improved by correlating
|> |>> messaging across several devices. This working group will
|> |>> define a correlation identifier to be used for the
|> |>> troubleshooting and the for correlation of logging
|> |>> information from different SIP devices in the network.
|> |>>> Sip transactions are often triggered by another SIP
|> |>> transaction. Two transactions are in the same "session" if
|> |>> one was triggered by the other due to redirection, REFER
|> |>> processing, retargeting, or forwarding on a B2BUA. This
|> |>> working group will define a correlation identifier that
|> |>> identifies  all the transactions in the same session.  The
|> |>> scope of the identifier pertains to the SIP signaling layer
|> |>> only, and not media.   For example, several UA participating
|> |>> in a conference call may be receiving the same media but
|> |>> would not be in the same session.
|> |>>> The design of the correlation identifier needs to take into
|> |>> account the issue of not revealing the topology of network.
|> |>> The mechanism should be applicable for Proxies, UAs, PBXs,
|> |>> SBCs, Application Servers, Softswitches, Phones, and Gateways.
|> |>>> This working group will coordinate with other relevant
|> |>> working groups and area including Ops, and sipcore.
|> |>>>
|> |>>>
|> |>>>
|> |>>>
|> |>>>
|> |>>> _______________________________________________
|> |>>> dispatch mailing list
|> |>>> [email-masked]
|> |>>> https://www.ietf.org/mailman/listinfo/dispatch
|> |>>>
|> |>>
|> |>>
|> |>> --
|> |>> Victor Pascual Ávila
|> |>> _______________________________________________
|> |>> dispatch mailing list
|> |>> [email-masked]
|> |>> https://www.ietf.org/mailman/listinfo/dispatch
|> |>>
|> |> _______________________________________________
|> |> dispatch mailing list
|> |> [email-masked]
|> |> https://www.ietf.org/mailman/listinfo/dispatch
|> |>
|> |_______________________________________________
|> |dispatch mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/dispatch
|> _______________________________________________
|> dispatch mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/dispatch
|>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Jul 2010 06:07:42 -0400

There are two "risks" to scoping this so narrowly:

1) "troubleshooting" is quite a broad and vague application.
    The correlation adopted will facilitate some class of issues,
    depending on the correlation function chosen. Some are likely
    to be disappointed.
    (I consider this risk to be "low", as those who care should
    speak up now. And possibly an upward compatible extension could
    be done later if the need were found.)

2) Other applications that require correlation of some class of
    related dialogs for some purpose other than troubleshooting
    are driven away, and so must define yet another header and id
    for their own purposes.
    (Whether this is bad or not is debatable. I know there are
    currently proprietary headers for such purposes, and *that*
    isn't so helpful in interop situations.)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Jul 2010 06:35:14 -0400

Hey John,
I have been told siprec would need it, but whenever I ask someone why it needs it no one can give me a clear answer.  As far as I can tell it doesn't.  I know that in some current recording environments we use a call identifier value other than Call-ID and tags, but as far as I can tell it's not the same as session-id would be.

As for why only troubleshooting - it's because every use-case we can think of for session-id has the potential to cause a middlebox to change the session-id, nullifying its value for troubleshooting.  I'm thinking that in the next rev of session-id draft I should actually add an appendix describing those use-cases and why it's dangerous for them.

-hadriel

> Behalf Of Elwell, John
> Sent: Friday, July 30, 2010 3:46 AM
> 
> Server to be able to correlate two recorded sessions from different
> Session Recording Clients. For example, if a customer call is transferred
> from one agent to a second agent, the two agents might be using different
> Session Recording Clients to send media to the Session Recording Server.
> What would be the barrier to using session ID for this case? Is it just
> the lack of guaranteed uniqueness, or are there other factors?
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Jul 2010 07:39:57 -0400

Is the requirement for SIPREC to correlate two SIP dialogs/messages as the same session, or is it really to correlate *media* streams as the same *media* session?  As far as I can tell, it's media streams you care about, not SIP messages.

That's a different problem.  For example, if there are two SIP sessions which are members of the same conference call, do you need to know they're the same or do you want to see them as separate?  Or for example in a forked call in which both forks end up being answered and survive, would both forks be considered the same session for recording or two separate ones?  Or for call-transferred calls, there are specific cases in which session-id will end up with two different id's for the final session (different on each side of a b2bua), which is arguably an acceptable deficiency of session-id for troubleshooting, but probably not for recording.

But IMHO, ultimately it doesn't matter even if they *are* the same semantics and scenarios.  Because as soon as you use session-id for Recording, someone will be compelled to change the session-id value in certain call cases - for example, so that they are recorded as separate sessions - at which point session-id's troubleshooting benefits go away.

-hadriel

> Behalf Of Hutton, Andrew
> Sent: Friday, July 30, 2010 5:23 AM
> 
> I think it is highly likely that correlating messages across several
> devices (I.e. two sides of a B2BUA) is going to be useful for more than
> just troubleshooting and agree that will be tool that can have many usages.
> 
> However the originator of the identifier cannot be expected to know what
> it is going to be used for so having an parameter specifying the usage
> does not make sense to me.
> 
> One example of how this might be useful to SIPREC is that it could be used
> to enable the recording system to identify that it recording the same
> session by two different recording clients.
> 
> I would like to see the charter for the session ID working group being
> less specific about the usage and the solution to allow the WG to
> formulate the use cases and associated requirements. Maybe this may result
> in more work for the WG but that would be better than having multiple
> solutions for essentially the same problem.
> 
> Regards
> Andy

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Jul 2010 07:44:21 -0400

> Behalf Of Paul Kyzivat
> Sent: Friday, July 30, 2010 6:08 AM
> 

I know adding more headers sucks.  But that may be the safest thing.

-hadriel

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 30 Jul 2010 17:47:33 +0530

Hadriel,

Instead working with solution in mind, Shall we start with the usecases
document. The usecase document will help us to decide whether the single
header or multiple header required. It will help to identify the generic
session-id if one exists. The usecase requirement will be very useful as
we are talking about the complex dialog scenarios which involves set of
B2BUA. 

As I mentioned in the earlier mail thread, I'll come up with the usecase
document as a starting point, add more relevant usecases and we will
brainstorm whether the usecases are relevant for the session id or not.
Please let me know your opinion on the same.

Thanks
Partha 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: Friday, July 30, 2010 5:14 PM
To: Paul Kyzivat (pkyzivat); Peter Musgrave
Cc: [email-masked] list
Subject: Re: [dispatch] Proposal for Session ID charter

-hadriel

---

From: Toto Shyardi <[email-masked]>
Date: Fri, 30 Jul 2010 07:51:47 -0500

> document. The usecase document will help us to decide whether the single

Short of the IETF solution, the 3GPP invented its own "session-id" for the
following application:

1. Assume UA-a has a voice dialog with UA-b (over access network X), and
there is a B2BUA between them.

2. During the voice dialog, the UA-a roams into access network Y. There is a
"small" overlap between networks X and Y (i.e. X*Y), and the UA-a is a
dual-radio device (it can simultaneously transmit in X and Y).

3. While in X*Y, UA-a establishes a second dialog (over Y), and indicates to
the UA-b that *this dialog replaced the original dialog *(by specifying the
dialog-id between the UA-a and B2BUA). It also terminates the original
dialog over the network X.

4. Obviously, the "handoff" fails, since the original dialog between the
UA-a and the B2BUA has different dialog-id then the dialog between the B2BUA
and the UA-b.

Hence, the need for some "session-id" that consists of concatenated dialogs.

Toto

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 30 Jul 2010 18:35:38 +0530

Toto,
 
Thanks for indicating about 3GPP session id. I'll include the below
mentioned usecase and provide 3GPP reference for more details. I'm
pretty sure that  we will hear much more as I heard that most of the
vendors have proprietary session-id for different applications with
different callflows. 
 
All,
 
Toto mail ascertain the requirement of usecase document for this
session-id mechanism. Please let me know in case any other opinion.
 
Thanks
Partha

________________________________

From: Toto Shyardi [mailto:[email-masked]] 
Sent: Friday, July 30, 2010 6:22 PM
To: Parthasarathi R (partr)
Cc: Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave;
[email-masked]
Subject: Re: [dispatch] Proposal for Session ID charter

On Fri, Jul 30, 2010 at 7:17 AM, Parthasarathi R (partr)
<[email-masked]> wrote:

	Hadriel,
	
	Instead working with solution in mind, Shall we start with the
usecases
	document. The usecase document will help us to decide whether
the single

Short of the IETF solution, the 3GPP invented its own "session-id" for
the following application:

2. During the voice dialog, the UA-a roams into access network Y. There
is a "small" overlap between networks X and Y (i.e. X*Y), and the UA-a
is a dual-radio device (it can simultaneously transmit in X and Y).

3. While in X*Y, UA-a establishes a second dialog (over Y), and
indicates to the UA-b that this dialog replaced the original dialog (by
specifying the dialog-id between the UA-a and B2BUA). It also terminates
the original dialog over the network X.

4. Obviously, the "handoff" fails, since the original dialog between the
UA-a and the B2BUA has different dialog-id then the dialog between the
B2BUA and the UA-b.

Hence, the need for some "session-id" that consists of concatenated
dialogs. 

Toto