[Sipping] Re: draft-camarillo-sip-body-handling-01 and draft-bryan-sipping-midi-01

[Paul Kyzivat <[e-mail]>]

(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:
> On 4 Jun 2007, at 20:50, [e-mail] 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 [e-mail] 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 [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 


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