[Speermint] Missing media in draft-hancock-sip-interconnect-guidelines-01.txt

["Gunnar Hellstrom" <gunnar.hellstrom at omnitor.se>]

I find it very sad to limit the scope of this specification to audio only,
and ask to widen the scope at least to real-time conversational sessions
including real-time text, video and audio.

One motivation is that the work with emergency service calls in ECRIT
require a possibility to use real-time text, video and audio in emergency
calls. Such calls might need to be routed over a sip interconnection, and
thus need to get full support for its media. ( emergency calls are within
the scope list of this draft. )

There are a number of other valid reasons for this request.

Hoping that it can accepted, I give here a first set of edit proposals to
bring the draft up to proper multimedia status.

****************************************
In 1.1  change from
"1.1.  Scope

   The document focuses on the interworking procedures required to
   support basic telephone service, including the following
   capabilities:

   o  On-net to on-net calls
"
To
"
1.1.  Scope

   The document focuses on the interworking procedures required to
   support basic real-time conversational service, including the following
   capabilities:

   o  Video
   o  Real-time text
   o  On-net to on-net calls
"

In 5.1.1.  change from
"
5.1.1.  SDP Requirements

   SIP entities involved in session peering MUST support the SDP
   requirements defined in [RFC4566].  A SIP entity involved in session
   peering MUST include only one media (m=) descriptor in an SDP offer
   to a peer network.  If a SIP entity involved in session peering
   receives an SDP offer containing multiple media descriptors, it
   SHOULD act on the first audio descriptor with a non-zero port.
"
To
"
5.1.1.  SDP Requirements

   SIP entities involved in session peering MUST support the SDP
   requirements defined in [RFC4566].  A SIP entity involved in session
   peering MUST include only one media (m=) descriptor per desired media
   stream in an SDP offer to a peer network.  

   If a SIP entity involved in session peering receives an SDP offer
   containing multiple media descriptors, it MUST act on the media
   descriptors and include all of them in the same order in the
   response, including non-zero ports and zero ports for the offered
   media according to its capabilities as specified in [RFC 3264]
   Offer - Answer model. An offered session MUST NOT be rejected
   because it offers more media than the responding entity can handle.
"

These wew just the apparent initial edits after rapid browsing of the draft.
There is likely more to do to complete the topic.
-

/Gunnar


-----Original Message-----
From: i-d-announce-bounces at ietf.org [mailto:i-d-announce-bounces at ietf.org]
On Behalf Of Internet-Drafts at ietf.org
Sent: Monday, July 13, 2009 9:00 PM
To: i-d-announce at ietf.org
Subject: I-D Action:draft-hancock-sip-interconnect-guidelines-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : draft-hancock-sip-interconnect-guidelines-01
	Author(s)       : D. Hancock, D. Malas
	Filename        : draft-hancock-sip-interconnect-guidelines-01.txt
	Pages           : 25
	Date            : 2009-07-13

As Session Initiation Protocol (SIP) peering becomes more widely accepted by
service providers the need to define an interconnect guideline becomes of
greater value.  This document takes into consideration the SIP and commonly
used SIP extensions, and it defines a fundamental set of requirements for
SIP Service Providers
(SSPs) to implement within their signaling functions (SFs) or Signaling Path
Border Elements (SBEs) for peering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hancock-sip-interconnect-guideline
s-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.