Subject: Re: [siprec] #36: Do we need REQ-030 on identifying a session as an RS?

From: "siprec issue tracker" <[email-masked]>
Date: Tue, 07 Sep 2010 11:00:00 -0000

#36: Do we need REQ-030 on identifying a session as an RS?
------------------------------------------------+---------------------------
 Reporter:  john.elwell@…                       |       Owner:  john.elwell@…                     
     Type:  defect                              |      Status:  assigned                          
 Priority:  minor                               |   Milestone:                                    
Component:  Requirements                        |     Version:                                    
 Severity:  Active WG Document                  |    Keywords:                                    
------------------------------------------------+---------------------------
Changes (by john.elwell@…):

  * status:  new => assigned

Comment:

 I just noticed this had been passed back to me - the tracker should have
 told me, but perhaps I missed it.

 The present REQ-030 states:
 "REQ-030 The mechanism MUST provide a means for the Recording
    Session identifier so that the Recording Session itself is labeled as
    a SIP session that is established for the purpose of recording."
 This doesn't parse. I think what it is trying to say is something similar
 to what was proposed when the ticket was opened:
 "REQ-030 The mechanism MUST enable the Recording Session to identify
 itself as a SIP session established for the purpose of recording."
 Alternatively, can REQ-030 be deleted, since it is perhaps a logical
 consequence of REQ-000.

 John

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/36#comment:2>
siprec <http://tools.ietf.org/siprec/>

---

From: Deepanshu <[email-masked]>
Date: Thu, 09 Sep 2010 09:24:08 +0800

I would suggest to keep current REQ-30 as explicit requirement because this
*is* a critical requirement for SIPREC.

Regards

Deepanshu Gautam
Tel: +86 25 56620008, Mob: +86 13585147627
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
siprec issue tracker
Sent: 2010年9月7日 19:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [siprec] #36: Do we need REQ-030 on identifying a session as an
RS?

#36: Do we need REQ-030 on identifying a session as an RS?
------------------------------------------------+---------------------------
 Reporter:  john.elwell@…                       |       Owner:
john.elwell@…                     
     Type:  defect                              |      Status:  assigned

Comment:

 John

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

---

From: "siprec issue tracker" <[email-masked]>
Date: Thu, 09 Sep 2010 08:03:27 -0000

Comment(by krehor@…):

 (BTW I didn't intend to move this one back to you John...)

 I think there's a typo in the current version. I believe we meant (my
 emphasis):

 REQ-030 The mechanism MUST provide a means for *a* Recording Session
 identifier
 so that the Recording Session itself is labeled as a SIP session that is
 established for the purpose of recording.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/36#comment:3>
siprec <http://tools.ietf.org/siprec/>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 9 Sep 2010 10:06:30 +0200

Deepanshu,

Fine, I can agree to keep the requirement, but I would prefer to change the wording, as proposed.

John

> From: Deepanshu [mailto:[email-masked]] 
> Sent: 09 September 2010 02:24
> To: 'siprec issue tracker'; Elwell, John; [email-masked]
> Cc: [email-masked]
> Subject: RE: [siprec] #36: Do we need REQ-030 on identifying 
> a session as an RS?
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
> siprec issue tracker
> Sent: 2010年9月7日 19:00
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/siprec/trac/ticket/36#comment:2>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 9 Sep 2010 10:19:33 +0200

OK

John 

> From: siprec issue tracker [mailto:[email-masked]] 
> Sent: 09 September 2010 09:03
> To: Elwell, John; [email-masked]
> Cc: [email-masked]
> Subject: Re: [siprec] #36: Do we need REQ-030 on identifying 
> a session as an RS?
> 
>  Reporter:  john.elwell@...                       |       
> Owner:  john.elwell@...                     
>      Type:  defect                              |      
> Status:  assigned                          
>  Priority:  minor                               |   
> Milestone:                                    
> Comment(by krehor@...):
> <http://trac.tools.ietf.org/wg/siprec/trac/ticket/36#comment:3>

---

From: "Dave Smith" <[email-masked]>
Date: Mon, 13 Sep 2010 16:37:37 -0700

I'd agree that this req't is not necessary - it is an obvious conclusion from REQ-000 and REQ-033 and so does not need to be explicitly stated.   

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of siprec issue tracker
Sent: Thursday, September 09, 2010 1:03 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [siprec] #36: Do we need REQ-030 on identifying a session as an RS?

Comment(by krehor@…):

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "siprec issue tracker" <[email-masked]>
Date: Thu, 16 Sep 2010 15:11:21 -0000

Comment(by henry.lum@…):

 Responding to Dave's comment:

 "I'd agree that this req't is not necessary - it is an obvious conclusion
 from REQ-000 and REQ-033 and so does not need to be explicitly stated."

 There is one minor exclusion in the REQ-000 and I think it's worth
 mentioning that we need to identify a SIP session as a recording session.
 From my conversation with a few others, it may be not clear why we need to
 identify a recording session. Here are a few reasons why:

 - For routing elements (SIP Proxy) to identify recording session for
 routing to the SRC or the SRS.
 - An SRC usually have multiple duties such as handling a CS. If an SRS
 initiates a recording session to the SRC, then the SRC needs a way to
 identify that the SIP session is for the purpose of recording and not for
 a CS.
 - An SRS may support SIP sessions other than recording sessions, for
 example, an SRS may support SIP sessions for playback of recording.

 Perhaps we should add a use case to clarify?

 Also, I like John's re-word as well:
 "REQ-030 The mechanism MUST enable the Recording Session to identify
 itself as a SIP session established for the purpose of recording.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/36#comment:4>
siprec <http://tools.ietf.org/siprec/>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Sep 2010 12:18:13 -0400

In the abstract I have no problem with this requirement.
But we need to be a bit careful about how we propose that it be 
implemented/used.

This seems a bit like tagging a call as an "emergency" call, with the 
expectation that it will then get expedited service. The problem is that 
it can invite abuse/misuse. In the case of emergency calling the 
decision was to use the destination address (i.e. URN service:sos) both 
to route the call and to decide it should get special handling. That 
can't be abused to get special handling to a different destination 
because it is the destination that causes the special handling.

I think similar issues apply here. What if you tag a call as a recording 
session, but send it someplace where that makes no sense?

I would think that the R-URI would be sufficient to identify that the 
request was destined for an SRC or SRS.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 20 Sep 2010 14:49:30 +0200

> Sent: 16 September 2010 16:11
> To: Elwell, John; [email-masked]; [email-masked]
> Cc: [email-masked]
> Comment(by henry.lum@...):
> 
[JRE] I am not necessarily agreeing with this requirement, but, if the requirement is agreed, I would expect somehow to make use of the caller preferences mechanism to satisfy this requirement.

>  identify that the SIP session is for the purpose of 
[JRE] Other duties would not be part of the SRC - the SRC is a logical entity that might be collocated with other functions on the same piece of equipment.  As already suggested, the URI could identify the entity concerned.

>  example, an SRS may support SIP sessions for playback of recording.
[JRE] Again, the SRS is the logical entity that handles a Recording Session. It might be collocated with other functions (such as playback) on the same piece of equipment. Again, the URI could identify the entity concerned.

>  itself as a SIP session established for the purpose of recording.
[JRE] And one such mechanism would be through the use of different URIs.

John (as individual)

> 
> -- 
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/siprec/trac/ticket/36#comment:4>

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 20 Sep 2010 09:53:36 -0700

I agree RURI should be sufficient to route the request to SRC/SRS; I'll take back my first comment on the reasons for needing REQ-030.

Henry

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, September 16, 2010 12:18 PM
> To: siprec issue tracker
> Cc: [email-masked]; Henry Lum; [email-masked];
> [email-masked]

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 23 Sep 2010 15:51:20 +0200

Hi,

I think that REQ-030 is needed.

It is I think important that any middleboxes used to route the request to establish the recording session have the chance to take special action if they understand that this is a recording session.

For example if a middlebox is acting as an appearance agent for shared appearances (See http://tools.ietf.org/html/draft-ietf-bliss-shared-appearances-06#section-5.4) then it may need to know that this is not a dialog that requires an appearance to be allocated. I am sure there are other examples if we think hard enough.

Regards
Andy

> [mailto:[email-masked]] On Behalf Of Henry Lum
> Sent: 20 September 2010 17:54
> To: Paul Kyzivat; siprec issue tracker
> Cc: [email-masked]
> I agree RURI should be sufficient to route the request to 
> SRC/SRS; I'll take back my first comment on the reasons for 
> needing REQ-030.
> 
> Henry
> 
> > Subject: Re: [siprec] #36: Do we need REQ-030 on 
> identifying a session
> > as an RS?
> > 
> > >   Reporter:  john.elwell@...                       |       Owner:
> > john.elwell@...
> > >       Type:  defect                              |      Status:
> > assigned
> > >   From my conversation with a few others, it may be not 
> clear why we
> > need to
> > >   - An SRC usually have multiple duties such as handling 
> a CS. If an
> > SRS
> > >   initiates a recording session to the SRC, then the SRC 
> needs a way
> > to
> > >   identify that the SIP session is for the purpose of 
> recording and
> > not for
> > >   a CS.
> --------------------------------------------------------------
> -----------------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached 
> may contain confidential and proprietary information of 
> Alcatel-Lucent and/or its affiliated entities. Access by the 
> intended recipient only is authorized. Any liability arising 
> from any party acting, or refraining from acting, on any 
> information contained in this e-mail is hereby excluded. If 
> you are not the intended recipient, please notify the sender 
> immediately, destroy the original transmission and its 
> attachments and do not disclose the contents to any other 
> person, use it for any purpose, or store or copy the 
> information in any medium. Copyright in this e-mail and any 
> attachments belongs to Alcatel-Lucent and/or its affiliated entities.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Sep 2010 10:52:46 -0400

Andrew,

If you intend middleboxes to take special action based on this 
indicator, please think about what will happen if it is wrong. In 
particular, can anything get some special advantage by claiming this 
property when it does not apply.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 23 Sep 2010 17:43:26 +0200

Paul,

The indication is needed for the benefit of the middlebox itself not for the benefit of the originator. The inclusion of this information helps the middlebox decide how to handle the session in terms of it's own feature interactions.

An endpoint that initiates recording sessions without stating the purpose of the session could be considered the one that is trying to gain advantage for example a middlebox may consider recording sessions to be of lower priority.

Regards
Andy

> Sent: 23 September 2010 15:53
> To: Hutton, Andrew
> Cc: Henry Lum; siprec issue tracker; [email-masked]
> > It is I think important that any middleboxes used to route 
> the request to establish the recording session have the 
> chance to take special action if they understand that this is 
> a recording session.
> >
> > For example if a middlebox is acting as an appearance agent 
> for shared appearances (See 
> http://tools.ietf.org/html/draft-ietf-bliss-shared-appearances
> -06#section-5.4) then it may need to know that this is not a 
> dialog that requires an appearance to be allocated. I am sure 
> there are other examples if we think hard enough.
> >
> > Regards
> > Andy
> >
> >
> >>> expectation that it will then get expedited service. The 
> problem is
> >>> that
>    Owner:
> >>>>    mentioning that we need to identify a SIP session as 
> a recording
> >>> session.
> >>>>    - For routing elements (SIP Proxy) to identify 
> recording session
> >>> for
> >>>>    - An SRS may support SIP sessions other than 
> recording sessions,
> >>> for

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Sep 2010 20:59:58 -0400

As long as there is no illicit benefit to be gained by lying, then I 
guess its ok.

	Thanks,
	Paul

---

From: Deepanshu <[email-masked]>
Date: Tue, 28 Sep 2010 14:12:14 +0800

Paul

I have a question for clarification regarding this old thread

I think we already have draft "draft-johnston-siprec-cc-rec-00" providing a
solution for this requirement i.e using feature tag (src and srs).Keeping
that in mind, are you suggesting to use R-URI instead.

Regards

Deepanshu Gautam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: 2010年9月17日 0:18
To: siprec issue tracker
Cc: [email-masked]; [email-masked]
Subject: Re: [siprec] #36: Do we need REQ-030 on identifying a session as an
RS?

	Thanks,
	Paul

john.elwell@…

---

From: "siprec issue tracker" <[email-masked]>
Date: Tue, 28 Sep 2010 07:50:23 -0000

#36: Do we need REQ-030 on identifying a session as an RS?
------------------------------------------------+---------------------------
 Reporter:  john.elwell@…                       |       Owner:  krehor@…        
     Type:  defect                              |      Status:  new             
 Priority:  minor                               |   Milestone:                  
Component:  Requirements                        |     Version:                  
 Severity:  Active WG Document                  |    Keywords:                  
------------------------------------------------+---------------------------
Changes (by krehor@…):

  * owner:  john.elwell@… => krehor@…
  * status:  assigned => new

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/36#comment:5>
siprec <http://tools.ietf.org/siprec/>

---

From: "siprec issue tracker" <[email-masked]>
Date: Tue, 28 Sep 2010 07:51:22 -0000

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/siprec/trac/ticket/36#comment:6>
siprec <http://tools.ietf.org/siprec/>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Sep 2010 08:37:09 -0400

> that in mind, are you suggesting to use R-URI instead.

I'm not really suggesting anything in particular right now.
I'm still trying to understand the point of the requirement.
What is expected to happen as a result of this indication that would not
happen without it?

If the expectation is that the request will get some favored treatment,
then I'm concerned about using an indication that anyone can add without
any negative consequence of doing so inappropriately.

	Thanks,	
	Paul