supplementary media formats; RE: [ams-design] Granularity of micro-applications

Paul,
 
we got a similar discussion for H.248.
We did introduce the notion of "supplementary media formats", see
H.248 Sub-series Implementors' Guide (Rev.)
http://www.itu.int/md/T05-SG16-080422-TD-PLEN-0474/en
 
-Albrecht
 
7.1.7.1.3   ReserveValue

...

Note:  A single set of property values may consist of a single media
type (e.g. audio or video) related media format complemented by a list
of supplementary media formats. Supplementary media formats are for
example:

*        Comfort noise ([IETF RFC 3389]),

*        RTP Payload for DTMF digits, telephony tones and telephony
signals ([IETF RFC 4733]),

*        Voiceband data (VBD) services (according to [ITU-T V.152]),

*        or other auxiliary media (e.g. inband signaling) associated to
the main media flow.

 

... 
________________________________

From: [email protected]
[mailto:[email protected]] On Behalf Of Robert
Jongbloed
Sent: Dienstag, 10. Juni 2008 02:56
To: [email protected]
Subject: Re: [ams-design] Granularity of micro-applications



	My $0.02

	 

	The apps should be logically distinct entities, always being
from the "user" perspective. While the line could be blurred as in DTMF
(they are tones so aren't they voice?) it is still a distinct function.
A Bluetooth earpiece could do voice but not DTMF, and the DTMF for the
same call is done by a separate entity, the handset. So I think there
should be separate "uii_app" and "fax_app".

	 

	Dealing with things like RFC2833 means there may need to be a
multiplexing capability (somehow) at the app to container boundary. Or
perhaps some mechanism for peer to peer communication between apps.

	 

	 

	Robert Jongbloed

	OPAL/OpenH323 Architect and Co-founder.

	 

	From: [email protected]
[mailto:[email protected]] On Behalf Of Paul E.
Jones
	Sent: Tuesday, 10 June 2008 8:42 AM
	To: [email protected]
	Subject: [ams-design] Granularity of micro-applications

	 

	Folks,

	 

	One of the things that has been sitting in the back of my mind
is the granularity of micro-applications.  Originally, I had proposed
that we might have a "voice_app" and a "video_app", for example.  But,
what constitutes a "voice_app"?  Does that include DTMF or would that be
separate?  (Given that we would need to multiplex DTMF within the audio
path - due to the unfortunate use of RFC 2833 - it might make sense for
DTMF to be a function of the voice_app.)

	 

	But, what about fax?  Fax could arguably be separated entirely.
In fact, I'm wondering if we ought to solicit the help of Q14/16 in the
design of a fax_app that might be used in AMS.

	 

	The thinking is that a typical PSTN GW might advertise that it
has the voice_app and fax_app and modem_app applications.  These would
not be operating in parallel, obviously.  So, when a fax tone is
detected, a transition could be made from the voice_app to the fax_app.

	 

	Does that kind of separation make sense, or do you think that
the fax functionality ought to be defined as a part of the voice_app?

	 

	My thinking is that by separating the voice_app and fax_app, we
not only define a cleaner and simpler voice_app, but it would also allow
an AMS user to walk up to a fax machine, for example, and receive a fax
while talking on the phone, as the fax_app would be invoked in parallel.

	 

	Paul

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco