I-D ACTION:draft-ietf-mmusic-sdp-cs-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title		: Session Description Protocol (SDP) Extension For Setting Up Audio Media Streams Over
Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)
	Author(s)	: M. Garcia-Martin, S. Veikkolainen
	Filename	: draft-ietf-mmusic-sdp-cs-00.txt
	Pages		: 25
	Date		: 2009-2-25
	
   This memo describes use cases, requirements, and protocol extensions
   for using the Session Description Protocol (SDP) Offer/Answer model
   for establishing audio media stream over circuit-switched bearers in
   the Public Switched Telephone Network (PSTN).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-00.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.

_______________________________________________
mmusic mailing list

Re: RTSP: Contradicting text in RFC2326bis and RFC 2616

Martin Stiemerling skrev:
> Hi all,
> 
> Just to clarify the intended use of the Date header field.
> 
> draft-ietf-mmusic-rfc2326bis-19.txt says this in Section 16.20. "Date":
> 
>    See [H14.18].  An RTSP message containing a body MUST include a Date
>    header if the sending host has a clock.  Servers SHOULD include a
>    Date header in all other RTSP messages.
> 
> When adding the text out of [H14.18] to RFC2326bis we end up with this,
> as the text "Servers SHOULD include a Date header in all other RTSP
> messages." contradicts the text in RFC 2616:
> 
>    Origin servers MUST include a Date header field in all responses,
>    except in these cases:
> 
>    1.  If the response status code is 100 (Continue) or 101 (Switching
>        Protocols), the response MAY include a Date header field, at the
>        server's option.
> 
>    2.  If the response status code conveys a server error, e.g. 500
>        (Internal Server Error) or 503 (Service Unavailable), and it is
>        inconvenient or impossible to generate a valid Date.
> 
>    3.  If the server does not have a clock that can provide a reasonable
>        approximation of the current time, its responses MUST NOT include
>        a Date header field.  In this case, the rules in section 14.18.1
>        MUST be followed.

Re: RTSP From header issue

Ingemar Johansson S skrev:
> Hi
> 
> Going through the syntax of the parts that handles URI's I found a possible issue with the syntax of the From
header. 
> 1) In section 16.23 in RTSP 2.0 there is only a reference section 14.22 in RFC2616 which contains a rather
simple definition.
>        From   = "From" ":" mailbox
> Section 20.2.3 in RTSP 2.0 however contains a much more elaborate definition with extensions
(from-param). 
> Isn't it better to specify something in section 16.23 like "The From header is defined in in [H14.22] but is
extended in this specification" ?

I hope Martin Fixes this if we are keeping the header.

> 
> 2) Looking at the syntax I see a risk that occasional ";" in the URI can clash with URI's that precedes each
optional from-param, making parsing complicated.
> The ABNF for the From header is
>    From           =  "From" HCOLON from-spec
>    from-spec      =  ( name-addr / addr-spec ) *( SEMI from-param )
>    name-addr      =  [ display-name ] LAQUOT addr-spec RAQUOT
>    addr-spec      =  RTSP-URI / absolute-URI
>    absolute-URI   =  < As defined in RFC 3986>
>    display-name   =  *(token LWS) / quoted-string
>    from-param     =  tag-param / generic-param
>    tag-param      =  "tag" EQUAL token
> 
> Here I would suggest to change the addr-spec definition to 
>    addr-spec      =  DQ ( RTSP-URI / absolute-URI ) DQ

Re: RTSP: Handling Media Clock Time Jumps in the RTP MediaLayer

Hi Ingemar,

The RTSP already includes a mechanism that handles this generic. It is
called RTP-Info headers seq parameter. That provides the client with an
indication of what the first packet is so that it can take the
appropriate action. As what is appropriate is varying with codecs etc I
am hesitant to write up to much about this. Do you have a text proposal?

Cheers

Magnus

Ingemar Johansson S skrev:
> Hi
> 
> In my opinion it would anyway be good to have some text around this with
> a recommendation that the RTP stack (including the jitter buffer) is
> reset when a timestamp glitch occurs.
> We have quite recently had a discussion around crappy RTP stack
> implementations that do RTCP-SR the wrong way, it does not mean that the
> implementers are stupid, just that the specification is vague and leaves
> room for alternative implementation. I can understand that we cannot
> document every odd feature but in this case I believe it does not cost
> much to have some extra text around this issue in the RTSP spec.
> 
> Regards
> Ingemar
> 
>> -----Original Message-----
>> From: Rémi Denis-Courmont [mailto:rem <at> videolan.org]

I-D ACTION:draft-ietf-mmusic-media-loopback-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title		: An Extension to the Session Description Protocol (SDP) for Media Loopback
	Author(s)	: N. Venna, P. Jones, A. Roychowdhury, K. Hedayat
	Filename	: draft-ietf-mmusic-media-loopback-10.txt
	Pages		: 33
	Date		: 2009-2-18
	
The wide deployment of Voice over IP (VoIP), Real-time Text and 
    Video over IP services has introduced new challenges in managing 
    and maintaining voice/real-time Text/video quality, reliability, 
    and overall performance.  In particular, media delivery is an area 
    that needs attention.  One method of meeting these challenges is 
    monitoring the media delivery performance by looping media back to 
    the transmitter.  This is typically referred to as "active 
    monitoring" of services.   Media loopback is especially popular in 
    ensuring the quality of transport to the edge of a given VoIP, 
    Real-time Text or Video over IP service.  Today in networks that 
    deliver real-time media, short of running 'ping' and 'traceroute' 
    to the edge, service providers are left without the necessary tools 
    to actively monitor, manage, and diagnose quality issues with their 
    service.  The extension defined herein adds new SDP media 
    attributes which enables establishment of media sessions where the 
    media is looped back to the transmitter. Such media sessions will 
    serve as monitoring and troubleshooting tools by providing the 
    means for measurement of more advanced VoIP, Real-time Text and 
    Video Over IP performance metrics.

Re: WGLC: draft-ietf-mmusic-connectivity-precon-05.txt

> -----Original Message-----
> From: mmusic-bounces <at> ietf.org 
> [mailto:mmusic-bounces <at> ietf.org] On Behalf Of Jean-Francois Mule
> Sent: Friday, February 27, 2009 8:32 AM
> To: Gonzalo Camarillo
> Cc: fandreas <at> cisco.com; oran <at> cisco.com; Joerg Ott; 
> dwing <at> cisco.com; mmusic <at> ietf.org
> Subject: Re: [MMUSIC] WGLC: 
> draft-ietf-mmusic-connectivity-precon-05.txt
> 
> Gonzalo,
> 
>    First, as indicated privately to you, my apologies for the delay in
> getting to this.
> 
>    Reviewing the draft while doing the proto write-up, I have a few
> comments that need to be discussed.  The main one is the use of the
> defunct RTP No-op mechanism in avt in several places in the document.
> 
>    Please read below and let me know if you think it is fair to update
> the document.  If you think it would cause additional delays 
> for no good
> reasons, I could be convinced to put some editorial changes 
> in the proto
> write-up.
> 
> Jean-Francois.
> 
> 

RFC 5432 on Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5432

        Title:      Quality of Service (QoS) Mechanism 
                    Selection in the Session Description Protocol 
                    (SDP) 
        Author:     J. Polk, S. Dhesikan, G. Camarillo
        Status:     Standards Track
        Date:       March 2009
        Mailbox:    jmpolk <at> cisco.com, 
                    sdhesika <at> cisco.com, 
                    Gonzalo.Camarillo <at> ericsson.com
        Pages:      9
        Characters: 17614
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-mmusic-qos-identification-03.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5432.txt

The offer/answer model for the Session Description Protocol (SDP)
assumes that endpoints somehow establish the Quality of Service (QoS)
required for the media streams they establish.  Endpoints in closed
environments typically agree out-of-band (e.g., using configuration
information) regarding which QoS mechanism to use.  However, on the Internet, there is more than one QoS
service available.  Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use
for a particular media stream.  This document defines such a mechanism.  

Re: RTSP: Contradicting text in RFC2326bis and RFC 2616

Fixed in the draft. 
Text is in the CVS:
http://rtspspec.cvs.sourceforge.net/viewvc/rtspspec/draft-ietf-mmusic-rfc2326bis/draft-ietf-mmusic-rfc2326bis.xml?revision=1.166&view=markup

Thanks,

  Martin

stiemerling <at> nw.neclab.eu

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England
2832014 

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund <at> ericsson.com]
> Sent: Tuesday, March 03, 2009 4:38 PM
> To: Martin Stiemerling
> Cc: mmusic <at> ietf.org
> Subject: Re: [MMUSIC] RTSP: Contradicting text in RFC2326bis and RFC
> 2616
> 
> Martin Stiemerling skrev:
> > Hi all,
> >
> > Just to clarify the intended use of the Date header field.
> >
> > draft-ietf-mmusic-rfc2326bis-19.txt says this in Section 16.20.
> "Date":
> >

Re: RTSP From header issue

> -----Original Message-----
> From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On
> Behalf Of Magnus Westerlund
> Sent: Tuesday, March 03, 2009 4:48 PM
> To: Ingemar Johansson S
> Cc: mmusic <at> ietf.org
> Subject: Re: [MMUSIC] RTSP From header issue
> 
> Ingemar Johansson S skrev:
> > Hi
> >
> > Going through the syntax of the parts that handles URI's I found a
> possible issue with the syntax of the From header.
> > 1) In section 16.23 in RTSP 2.0 there is only a reference section
> 14.22 in RFC2616 which contains a rather simple definition.
> >        From   = "From" ":" mailbox
> > Section 20.2.3 in RTSP 2.0 however contains a much more elaborate
> definition with extensions (from-param).
> > Isn't it better to specify something in section 16.23 like "The From
> header is defined in in [H14.22] but is extended in this specification"
> ?
> 
> I hope Martin Fixes this if we are keeping the header.

There is now more text taken from H14.22 in the From section of RTSP. 

However, the "From" ABNF definition of RTSP does not include the H14.22 mailbox part anymore (at least from
my reading):
"The From request-header field, if given, SHOULD contain an Internet e-mail address for the human user who

Re: RTSP From header issue

Martin Stiemerling skrev:
>> -----Original Message-----
>> From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On
>> Behalf Of Magnus Westerlund
>> Sent: Tuesday, March 03, 2009 4:48 PM
>> To: Ingemar Johansson S
>> Cc: mmusic <at> ietf.org
>> Subject: Re: [MMUSIC] RTSP From header issue
>>
>> Ingemar Johansson S skrev:
>>> Hi
>>>
>>> Going through the syntax of the parts that handles URI's I found a
>> possible issue with the syntax of the From header.
>>> 1) In section 16.23 in RTSP 2.0 there is only a reference section
>> 14.22 in RFC2616 which contains a rather simple definition.
>>>        From   = "From" ":" mailbox
>>> Section 20.2.3 in RTSP 2.0 however contains a much more elaborate
>> definition with extensions (from-param).
>>> Isn't it better to specify something in section 16.23 like "The From
>> header is defined in in [H14.22] but is extended in this specification"
>> ?
>>
>> I hope Martin Fixes this if we are keeping the header.
> 
> 
> There is now more text taken from H14.22 in the From section of RTSP. 
> 
> However, the "From" ABNF definition of RTSP does not include the H14.22 mailbox part anymore (at least
from my reading):