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

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 31 Jul 2009 16:10:20 +0200

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: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, July 13, 2009 9:00 PM
To: [email-masked]
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.

---

From: Barry Dingle <[email-masked]>
Date: Sat, 1 Aug 2009 16:57:58 +1000

Hi,

I support the comments of Gunnar Hellstrom regarding the need for  strong
support of real-time text and video conversational services in addition to
voice in the SIP-Interconnect Guidelines.

RFC5012 (ECRIT Requirements) in Section 5 has a requirement Re4 which
states:

Re4.  Multi-mode communication:  IP-based emergency calls MUST support
multiple communication modes, including, for example,
      audio, video, and text.

      Motivation: Within the PSTN, voice and text telephony (often
called TTY or text-phone in North America) are the only commonly
      supported media.  Emergency calling must support a variety of
media.  Such media should include voice, conversational text (RFC
      4103 [RFC4103]), instant messaging, and video.

SPEERMINT must support these services at the Interconnect point as part of
support of access to Emergency Services if it is to be taken seriously as an
alternative Interconnect for public telecommunications based on IP.

/Barry

Barry Dingle
Fellow of University of Melbourne, Electrical and Electronic Eng., Australia

Fixed - +61(0)3-9725-3937    Mob - +61(0)41-911-7578
> Supporter of Linux + Open Source software

On Sat, Aug 1, 2009 at 12:10 AM, Gunnar Hellstrom <
[email-masked]> wrote:

> s-01.txt<http://www.ietf.org/internet-drafts/draft-hancock-sip-interconnect-guideline%0As-01.txt>
>
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speermint
>