Subject: [siprec] #24: Can we defer specifying RS establishment in direction SRS to SRC?

From: "siprec issue tracker" <[email-masked]>
Date: Fri, 25 Jun 2010 07:26:21 -0000

#24: Can we defer specifying RS establishment in direction SRS to SRC?
------------------------------------------------+---------------------------
 Reporter:  john.elwell@…                       |       Owner:  krehor@…        
     Type:  defect                              |      Status:  new             
 Priority:  major                               |   Milestone:                  
Component:  Requirements                        |     Version:                  
 Severity:  Active WG Document                  |    Keywords:                  
------------------------------------------------+---------------------------
 We have a requirement that it be possible to establish an RS in the
 direction SRS to SRC. This assumes that the SRS has access to data on
 which it can make a decision whether or not to record a CS (see
 ticket#23). Is it sufficient, at least for the first phase, to assume that
 the same out-of-band (outside scope of SIPREC) means by which the SRS
 learns about CSs being established can also be used to instruct the SRC to
 initiate an RS? Or do we instead need to be able to initiate the RS from
 SRS to SRC?

 John

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/24>
siprec <http://tools.ietf.org/siprec/>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Jun 2010 09:30:39 -0400

Another complication of SRS establishing RC with SRC is that the SRS 
must then know the address of the SRC. That may be easy in cases where 
the SRC is collocated with a CS participant, but whether that is true 
depends how the network is constructed.

(Of course going in the other direction requires the SRC to know the 
address of the SRS. But that seems an easier problem.)

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 25 Jun 2010 09:21:38 -0700

A related note to locating the SRC is that if the SRC can only initiate client connections due to the use of NAT or TLS, then the mechanism must also be compatible with RFC5626.

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: June-25-10 9:31 AM
> To: siprec issue tracker
> Cc: [email-masked]
> Subject: Re: [siprec] #24: Can we defer specifying RS establishment in
> direction SRS to SRC?
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

-------------------------------------------------------------------------------------------------------------------
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: Deepanshu Gautam <[email-masked]>
Date: Sat, 26 Jun 2010 10:56:55 +0800

Can SRC register (REGISTER) with SRS, irrespective of it location, while
loggin into the service?

Regards
Deepanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: 2010年6月25日 21:31
To: siprec issue tracker
Cc: [email-masked]
Subject: Re: [siprec] #24: Can we defer specifying RS establishment in
direction SRS to SRC?

Another complication of SRS establishing RC with SRC is that the SRS must
then know the address of the SRC. That may be easy in cases where the SRC is
collocated with a CS participant, but whether that is true depends how the
network is constructed.

(Of course going in the other direction requires the SRC to know the address
of the SRS. But that seems an easier problem.)

	Thanks,
	Paul

siprec issue tracker wrote:
> ------------------------------------------------+---------------------
> ------------------------------------------------+------

> ------------------------------------------------+---------------------
> ------------------------------------------------+------
> ticket#23). Is it sufficient, at least for the first phase, to assume
> that  the same out-of-band (outside scope of SIPREC) means by which
> the SRS  learns about CSs being established can also be used to
> instruct the SRC to  initiate an RS? Or do we instead need to be able
> to initiate the RS from  SRS to SRC?
>
>  John
>

---

From: "Jain, Rajnish" <[email-masked]>
Date: Sun, 27 Jun 2010 06:28:55 -0400

Deepanshu,

The address resolution issue is not unique to SIPREC. We should be able to leverage existing SIP mechanisms for that.

A fundamental premise behind SIPREC design is that SRC and SRS are peers (not master/slave). SRC registering to SRS implies ownership. I think that doesn't quite fit the problem space.

Raj

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Deepanshu Gautam [[email-masked]]
Sent: Friday, June 25, 2010 10:56 PM
To: 'Paul Kyzivat'; 'siprec issue tracker'
Cc: [email-masked]
Subject: Re: [siprec] #24: Can we defer specifying RS establishment in direction SRS to SRC?

Regards
Deepanshu

-----Original Message-----

        Thanks,
        Paul

DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.

---

From: "siprec issue tracker" <[email-masked]>
Date: Mon, 28 Jun 2010 07:50:31 -0000

Comment(by john.elwell@…):

 Posting Raj's comment here, since it seems to relate to this ticket:

 John

 Inline:

 > [DG]  I would like to see this feature (SRS->SRC) to be supported in the
 > first release. And I think it is not related with persistent recording
 > these are two different usecases.

 I agree that these are two different use cases. I also think that there is
 nothing fundamentally wrong about establishing RS from SRS to SRC. We've
 probably mischaracterized the issue. I believe the key issue is *metadata
 transport outside of RS SIP dialog*. I believe the reason some of these
 issues got mixed up is because typically for SRS to initiate an RS it must
 receive metadata.

 Some on the list have pointed out that SRS receiving metadata outside of
 RS SIP dialog is a CDR issue and should be treated outside the scope of
 SIPREC. I think we can live for that for now.

 Raj

-- 
Ticket URL: <https://trac.tools.ietf.org/wg/siprec/trac/ticket/24#comment:1>
siprec <http://tools.ietf.org/siprec/>

---

From: "siprec issue tracker" <[email-masked]>
Date: Mon, 28 Jun 2010 07:52:05 -0000

Posting Henry's comment here, since it seems to relate to this ticket:

 John

 > [LeonP] Yes, SRC->SRS. Our experience as SRS vendor tells us that it
 is
 > possible to support all use cases with this option. It just not will
 be
 > always cost effective or elegant: for example it will require
 > definition of the recording rules also on SRS and SRC sides

 [hlum] I do agree that SRC->SRS should cover all the use cases
 described, but I don't think the SRC side is required to have recording
 rules; SRC can always INVTE all calls to SRS, and SRS can reject some RS
 based on the recording rules. Of course SRC can also apply rules before
 it even attempts to establish the RS, but this is more of a choice of
 implementation.

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