Subject: [siprec] Adoption of material from draft-ram-siprec-metadata-format-02

From: "Elwell, John" <[email-masked]>
Date: Mon, 20 Jun 2011 13:01:53 +0200

Although there are some open issues, to be discussed during Thursday's call, I would like the WG to consider whether material in draft-ram-siprec-metadata-format-02 is ready for adoption into draft-ietf-siprec-metadata, i.e., bring it under WG control. In particular, between now and the call, please consider whether:
- the material is heading roughly in an acceptable direction;
- there are any issues that really should be closed before adoption;
- there are any aspects of the draft that should not be adopted at this time.

If, on the call or shortly afterwards, we can agree on adoption, the authors of the two drafts would be asked to perform a merger and publish a new version of draft-ietf-siprec-metadata before the cut-off for IETF#81 (2011-07-11).

John

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 20 Jun 2011 08:40:42 -0700

Hi John,

One general comment/question I have received from web application savvy
coworkers with whom I have discussed the contents of this draft is that
the metadata is essentially a document and HTTP already has well defined
mechanisms for document sharing and updating, so why not exchange an
HTTP address for the document and leverage those mechanisms instead of
sending all the metadata within SIP messages. My assumption is that the
requirement is to have a SIP based solutions that does not require an
HTTP server. Is that accurate?

Thanks,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Monday, June 20, 2011 4:02 AM
> To: [email-masked]
> Subject: [siprec] Adoption of material
fromdraft-ram-siprec-metadata-format-02
> 
> Although there are some open issues, to be discussed during Thursday's
call, I would like the WG to
> consider whether material in draft-ram-siprec-metadata-format-02 is
ready for adoption into draft-
> ietf-siprec-metadata, i.e., bring it under WG control. In particular,
between now and the call, please
> consider whether:
> If, on the call or shortly afterwards, we can agree on adoption, the
authors of the two drafts would
> be asked to perform a merger and publish a new version of
draft-ietf-siprec-metadata before the cut-
> off for IETF#81 (2011-07-11).
> 
> John
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jun 2011 13:59:30 -0400

Charles,

IIRC, the major driving forces were timeliness and synchronicity of 
metadata with the actual signaling, especially when initially 
establishing a RS, so that suitable decisions can be made about whether 
to record a session, etc.

AFAIK the avoidance of an HTTP server in the SRS wasn't a concern. (Its 
assumed in general to be a very capable box, and probably has an HTTP 
interface for querying, though that is out of our scope for now.) 
Avoiding an http client in the src might be slightly more significant, 
but I don't think that was much of a concern either.

Could we have skinned this cat with an http approach? Probably.
Obviously we had a lot more sip expertise than http expertise in the 
group. That may have been an influence as well.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 20 Jun 2011 20:47:29 +0200

Charles,

I don't recall whether we discussed non-SIP means for transporting metadata. We certainly discussed transmitting it separately from INVITE/UPDATE, and concluded that in most cases metadata changes would coincide with SDP updates, and therefore other SIP methods (such as INFO) would be less efficient.

By having a separate channel (HTTP) for metadata, there is the issue of synchronizing it with SDP updates. Certainly that would be achievable, but does it make the solution unnecessarily complicated?

XML document transport in SIP messages is certainly nothing new.

Furthermore, we have had only this one draft on metadata format/transport for several months. As the only candidate, we seemed to have reached, by default, a situation where it is only a question of when we adopt it, not if. So any other solution would require a draft very quickly, so that we can compare and contrast.

John

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: 20 June 2011 16:41
> To: Elwell, John; [email-masked]
> Subject: RE: [siprec] Adoption of material

---

From: Leon Portman <[email-masked]>
Date: Tue, 21 Jun 2011 12:02:08 +0300

Actually we had lot of discussion about this issue (metadata over SIP or over dedicated web service/HTTP) both internally and with partners.

Main advantages  (what I remember ) for SIP approach are as follows:
1. Simplicity, only one interface to implement, troubleshoot, secure and configure between SRC and SRS
2. RS SIP request is self-contained, it includes all relevant info in order to SRS to decide how to do recording . For example participants identity, location. So no need for SRS to correlate different messages from different interfaces
3. Footprint on SRC. For some implementation it is not feasible to have both SIP and HTTP stacks

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, June 20, 2011 9:00 PM
To: [email-masked]
Subject: Re: [siprec] Adoption of material fromdraft-ram-siprec-metadata-format-02

Charles,

IIRC, the major driving forces were timeliness and synchronicity of metadata with the actual signaling, especially when initially establishing a RS, so that suitable decisions can be made about whether to record a session, etc.

AFAIK the avoidance of an HTTP server in the SRS wasn't a concern. (Its assumed in general to be a very capable box, and probably has an HTTP interface for querying, though that is out of our scope for now.) Avoiding an http client in the src might be slightly more significant, but I don't think that was much of a concern either.

Could we have skinned this cat with an http approach? Probably.
Obviously we had a lot more sip expertise than http expertise in the group. That may have been an influence as well.

	Thanks,
	Paul

On 6/20/2011 11:40 AM, Charles Eckel (eckelcu) wrote:
> Hi John,
>
> One general comment/question I have received from web application 
> savvy coworkers with whom I have discussed the contents of this draft 
> is that the metadata is essentially a document and HTTP already has 
> well defined mechanisms for document sharing and updating, so why not 
> exchange an HTTP address for the document and leverage those 
> mechanisms instead of sending all the metadata within SIP messages. My 
> assumption is that the requirement is to have a SIP based solutions 
> that does not require an HTTP server. Is that accurate?
>
> Thanks,
> Charles
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 21 Jun 2011 22:21:43 +0530

Hi all,

I have raised non-SIP (HTTP, XMPP) mechanism for metadata as an open
item in SIPREC architecture document before IETF-80. The related link is
as follows:
http://www.ietf.org/mail-archive/web/siprec/current/msg01608.html. The
conclusion of IETF-80 SIPREC meeting is to use SIP as a mechanism which
is discussed at slide-7 of SIPREC architecture
(www.ietf.org/proceedings/80/slides/siprec-2.ppt). I attached the
specific slide content and notes of the meeting for your reference.

Thanks
Partha

Note:
Slide contents:
01 draft states some examples of how metadata could be delivered to the
SRC
SIP Headers. 
SDP.
Event Package.
INFO Package.
Non SIP Means.

Proposal - We seem to be converging on using INVITE/UPDATE on the RS
Dialog so state this. Keep non SIP means although outside SIPREC scope.

Conclusion in IETF-80:

Proposal: List INVITE/UPDATE + non-SIP means only for metadata delivery?
  Hadriel Kaplan: Agrees, but don't mention specific methods
    (e.g. INVITE/UPDATE)
  Keith Drage: Clarified that this repeats stuff in the protocol
document 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Leon Portman
Sent: Tuesday, June 21, 2011 2:32 PM
To: Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [siprec] Adoptionof material
fromdraft-ram-siprec-metadata-format-02

Actually we had lot of discussion about this issue (metadata over SIP or
over dedicated web service/HTTP) both internally and with partners.

Main advantages  (what I remember ) for SIP approach are as follows:
1. Simplicity, only one interface to implement, troubleshoot, secure and
configure between SRC and SRS 2. RS SIP request is self-contained, it
includes all relevant info in order to SRS to decide how to do recording
. For example participants identity, location. So no need for SRS to
correlate different messages from different interfaces 3. Footprint on
SRC. For some implementation it is not feasible to have both SIP and
HTTP stacks

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Monday, June 20, 2011 9:00 PM
To: [email-masked]
Subject: Re: [siprec] Adoption of material
fromdraft-ram-siprec-metadata-format-02

Charles,

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 23 Jun 2011 14:15:06 +0530

Hi all,

I haven't seen any closure for the below mail. In that scenario, it is
an (re-)open item in SIPREC architecture. In case lot of folks
interested in non-SIP (generic) based metadata passing mechanism, Let us
discuss in detail during today's Interim meeting and take an approach to
move forward. Also, draft-ram-siprec-metadata-format is designed with
the assumption that SIP will be used for passing metadata approach.

BTW, there was analyze on using "REST" XML approach for metadata passing
which will be more suitable for HTTP based interfaces but it is an
overkill for SIP based mechanism. It was highlighted in Slide-11 of
draft-ram-siprec-metadata-format presentation in IETF-80
(www.ietf.org/proceedings/80/slides/siprec-1.ppt). 

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Parthasarathi R (partr)
Sent: Tuesday, June 21, 2011 10:22 PM
To: Leon Portman; Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [siprec] Adoptionofmaterial
fromdraft-ram-siprec-metadata-format-02

Hi all,

Thanks
Partha

Note:
Slide contents:
SRC SIP Headers. 
SDP.
Event Package.
INFO Package.
Non SIP Means.

Conclusion in IETF-80:

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

Leon

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

Charles,

	Thanks,
	Paul