Subject: [Sipping] Re: I-D ACTION:draft-bryan-sipping-midi-01.txt

From: Colin Perkins <[email-masked]>
Date: Fri, 8 Jun 2007 15:27:38 +0100

On 4 Jun 2007, at 20:50, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Telephony Tones Using MIDI in SIP
> 	Author(s)	: C. Jennings, D. Bryan
> 	Filename	: draft-bryan-sipping-midi-01.txt
> 	Pages		: 68
> 	Date		: 2007-6-4
> 	
> This document describes conventions for using MIDI to generate tones
>    on SIP UAs.  This does not define any changes to SIP but describes
>    how to use the existing Alert-Info header to play tones that can be
>    used to indicate specialized PSTN tones such as the ringback tones
>    from various countries.  The tones are described using MIDI which
>    results in a compact representation that is simple for a UA to
>    generate and easy to render into audio.
>
>    This work is being discussed on the [email-masked] mailing list.
>    This draft was revived at request of a few people so it could be
>    discussed.  Parts of it need to be updated since it was written in
>    2003.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bryan-sipping-midi-01.txt

Interesting draft. A couple of comments:

How would this compare to sending audio/tone [RFC 4733 section 4.3.3]  
data in SIP? (I realise the audio/tone format is currently only  
defined for transport via RTP, but it could easily be extended for  
this use, and is simpler than MIDI).

Also, one could presumably achieve a similar effect using early media  
with either the RFC 4733 or RFC 4695 RTP payload formats. Some  
discussion of the trade-off between the approaches would be valuable.

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jun 2007 12:37:27 -0400

(I don't know whether to submit this to sip or sipping. I've picked 
sipping - I think the readership is much the same.)

I just noticed draft-bryan-sipping-midi-01, and wanted to use it as an 
example of issues related to Content-Disposition as discussed in 
draft-camarillo-sip-body-handling-01.

In the midi draft the Alert-Info header is being used to specify that a 
special ringback should be played, with the tone in a body part 
referenced by a CID: URI. The body part itself has:

    Content-Disposition: render;handling=optional

This is conformant to 3261, which specifies the Alert-Info header and 
allows it to contain any kind of URI.

However 3261 also specifies another way to convey altering info: a body 
part with a Content-Disposition of "alert". In particular Section 14.1 
of 3261 says:

    A UAC MAY choose not to add an Alert-Info header field or a body with
    Content-Disposition "alert" to re-INVITEs because UASs do not
    typically alert the user upon reception of a re-INVITE.

It appears that when this was written there was no thought to the 
possibility of using a CID URI, and so a second mechanism was provided 
for the case when the alerting data was being sent with the message.

IMO it is better to stick with a single mechanism, and use Alert-Info in 
all cases. But that still leaves the question of what the 
Content-Disposition type should be in this case in order to get the 
proper processing.

That is discussed in draft-camarillo-sip-body-handling-01. It says:

    UAs process message bodies and body parts in the following way.  On
    receiving a SIP message, if a body part is not referenced in any way
    (e.g., there are no header fields or other body parts with a
    Content-ID URL pointing to it), the UA processes the body part as
    indicated by its disposition type and the context in which the body
    part was received.

    OPEN ISSUE 4: this means that a UA would need to parse all body parts
    to find references between them before being able to fully process
    them.  If we are OK with this, we need to include text here
    explaining it.

    If the SIP message contains a reference to the body part, the UA
    processes the body part according to the reference and the
    disposition type of the body part.

I have some discomfort with the above, because it depends on processing 
of the entire message for references to body parts in order to decide 
how those body parts should be processed. IMO it would be better if the 
decision about processing body parts without references was independent 
of the processing of body parts based on a reference. By this I mean 
that if a body part has a disposition type that implies a certain type 
of processing, then that type of processing should be performed, whether 
or not there is a reference to it from elsewhere. And if a header 
references a body part, then the processing implied by that header 
should be applied regardless of whether or not the body part was 
processed independent of the reference.

This means that when constructing a message with a header that 
references a body part, the content disposition of the body part should 
be chosen so that something reasonable will be done if the recipient 
doesn't notice and process the header with the reference.

In the case of passing alerting information, using Alert-Info with a CID 
URI, I see three possible C-D values that might make sense:

- render
- alert
- ignore (hypothetical disposition)

A UA that *doesn't* process the Alert-Info header, or doesn't support 
CID as a URI type in the Alert-Info header would presumably behave as 
follows:

- render: hard to say how this might be handled. It might be rendered
   just as a ringback would. Or it might not be rendered until the call
   is answered, or it might be ignored, or rendered to some different
   device (speaker?) than the handset Its not at all well defined.

- alert: the UA should decide that this contains alerting info.
   It should alert with it appropriately, or decide that it doesn't
   wish to honor it.

- ignore: the UA should do nothing with this body part.

A UA that *does* process the Alert-Info header, and does support CID as 
a URI type in the Alert-Info would presumably behave as follows:

- render: treat as a ringback based on the Alert-Info. Also process
   the body on its own as above. If the independent processing was also
   as a ringback then all may be fine. Otherwise odd things occur,
   such as rendering it twice.

- alert: process as a ringback on its own and as a result of the
   Alert-Info. Seems like a reasonable result would occur.

- ignore: ignore on its own, and process as a ringback as a result
   of the Alert-Info - a reasonable result.

So in this case it seems that "render" is a risky choice. Either "alert" 
or "ignore" would be better. Since "ignore" is currently not defined, 
"alert" may be preferable. But I think "ignore" is cleaner, were it 
defined.

Then lets consider the results based on what Gonzalo has written in 
draft-camarillo-sip-body-handling-01:

- Regardless of the disposition, if the UA supports Alert-Info and
   CID then it should use this body to alert.

- If it doesn't wish to honor the Alert-Info it is still expected
   to detect that there is a CID reference, and suppress independent
   processing of the body part.

So, my feeling is:

- for now draft-bryan-sipping-midi-01 should probably recommend use
   of "alert" as the Content-Disposition type.

- we ought to define a new Content-Disposition type that means to
   ignore the body part in the absence of some other information
   about how to process it. This could be done as part of
   draft-camarillo-sip-body-handling-nn. And change the recommended
   body processing in that draft along the lines I have discussed here.

	Paul

Colin Perkins wrote:
> data in SIP? (I realise the audio/tone format is currently only defined 
> for transport via RTP, but it could easily be extended for this use, and 
> is simpler than MIDI).
> 
> --Colin Perkins

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 15 Jun 2007 13:30:52 -0700

>   of "alert" as the Content-Disposition type.
Yes good point. I'm not sure much will happen with draft due to other  
reasons but we had some request to resubmit it for discussion so we did.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 15 Jun 2007 13:27:03 -0700

> Interesting draft. A couple of comments:

Interesting is fair :-) David and I just resubmitted this based on a  
request of a few people want to have a current version to talk about.

>
> How would this compare to sending audio/tone [RFC 4733 section  
> 4.3.3] data in SIP? (I realise the audio/tone format is currently  
> only defined for transport via RTP, but it could easily be extended  
> for this use, and is simpler than MIDI).

Uh, this is likely larger, and far more complicated to implement for  
the receiver. I like the idea of using tones.

>
> Also, one could presumably achieve a similar effect using early  
> media with either the RFC 4733 or RFC 4695 RTP payload formats.  
> Some discussion of the trade-off between the approaches would be  
> valuable.

If we did go forward with something based on midi, it would need to  
be brought inline with 4695 but totally agree with you, the pro' s  
and con's of doing this in SIP signaling vs. what we have now where  
it is done in RTP with early media would need to be discussed.  
Including the interaction with HERFP.

---

From: Eric Burger <[email-masked]>
Date: Sun, 17 Jun 2007 20:51:35 +0900

Could we get the double-super-secret motivation for resubmitting the draft?

Is it for the originally stated purpose, to render standard ring-tones via
specification as MIDI files (because 3GPP supports MIDI?)?  If so, there are
probably better ways of doing this than in MIDI.   Most of the draft is (I
think, incorrect) ways to hack MIDI to generate tones that are almost the
real tones.

Is it to support custom ring-tones?  If so, I could really get on board.

I am not going to spend cycles on the draft unless I know what the
motivations are.  Knowing the motivations will dramatically alter the
direction I think the draft should go.

I do have an opinion on specifying the something in the INVITE instead of as
early media.  Early media is bad and evil and hard and very easy to have
weird stuff happen.  That should be enough, but for those who count every
byte, transporting a small set of MIDI events over RTP instead of sending a
Standard MIDI File means one has to pay the RTP and packet tax.  Thus, I
have no problem suggesting that one should NOT use RTP and early media for
such purposes.

I would also draw folks attention to:
draft-kosonen-sp-midi-mediatype

> Including the interaction with HERFP.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.