Mario and other modem experts,

There's a subtle point that needs to be made here, and that point is that there is a difference between SPRT being: - used in other specific applications (e.g., FoIP) on a case by case basis; and - available for general use by any application.

We (3Com / CommWorks) have no problem with SPRT being used in a specific application such as FoIP, if the fax experts to decide to do so. In the case of FoIP, we see the use of SPRT as valuable and support / encourage its use there.

We do have concerns with SPRT being made available for general use by any application, but the packet network transport protocol experts (i.e, the IETF) may decide to do so anyhow, if this were proposed to them.

The core of the issue here is that we are modem experts and we have decided to use SPRT for our application, i.e., MoIP. 3Com / Commworks fully supports that.

But now we as modem experts, not fax experts or, more importantly, not packet network transport protocol experts, must be careful to not overstep our boundaries: while not precluding the fax experts and the packet network transport protocol experts from using SPRT for their specific or general purposes if they choose to do so, we cannot make their decisions for them or do things in such a way that their opportunity to make their decisions is pre-empted. 3Com / CommWorks strongly opposes anything that would lead to this.

Jim

Mario Garakani mgarakan@cisco.com on 07/30/2002 02:26:45 PM

Please respond to Mario Garakani mgarakan@cisco.com

Sent by: Mario Garakani mgarakan@cisco.com

To: tr301@tiacomm.org cc: tr301@tiacomm.org Subject: Re: Multiple parameters on 'a' line: Please do help me understand

Mike,

We have had a couple of conversations in past TIA and ITU MoIP meetings, where Jim (3com) indicated his opinion that SPRT would be more easily adopted by IETF if it was known to be limited in its application. I agree with this assessment.

However, Cisco's has indicated in all past occasions that we "should not" limit SPRT to V.MoIP. There may be other very specific areas where SPRT could be quite useful, such as FoIP or bearer data (hdlc termination).

--- Mario

Michael_Nicholas@3com.com wrote:

Rajesh, Yes, we see the similarities between FoIP and MoIP, but in our minds, FoIP is not the proper analogy for MoIP. Silence Suppression may be a better analogy of extant protocols. We see MoIP more as a Codec type, not a Media Type. If Fax is detected, MoIP can switch to FoIP as it exists if MoIP is a

Codec

type just as other Codec types such as G.711 or G.723 currently do.

This

is not an issue.

Rajesh, You are now proposing that SPRT will be used non-MoIP? In previous meetings the issue was brought up that allowing SPRT to be used for non-MoIP applications would unnecessarily delay MoIP consent due to much longer and more rigorous IETF examination. Cisco said then that

SPRT

would not be used for non-MoIP so that was a non-issue. Now you are

making

it an issue again.

---------------------- Forwarded by Michael Nicholas/MW/US/3Com on 07/26/2002 03:57 PM ---------------------------

"Rajesh Kumar" rkumar@cisco.com on 07/26/2002 03:31:37 PM

Please respond to "Rajesh Kumar" rkumar@cisco.com

Sent by: "Rajesh Kumar" rkumar@cisco.com

To: tr301@tiacomm.org cc: bfoster@cisco.com, James Renkel/MW/US/3Com, tr301@tiacomm.org, tsg16q11@itu.int Subject: RE: Multiple parameters on 'a' line: Please do help me

understand

Modem experts,

I suggest we use an ITU FoIP precedent to resolve this MoIP issue.

Attached

is the latest, approved version of ITU T.38. Go to Annex D which

formulates

part of the SDP for T.38 as (copied verbatim):

m=image 49170 udptl t38

Mapping this into the RFC 2327 template for the 'm' line (copied

verbatim):

m=<media> <port> <transport> <fmt list>

we may conclude that, for FoIP, the transport protocol is 'UDPTL' and

the

media format is "T.38".

Since FoIP and MoIP must work seamlessly for the same endpoints, we can postulate that "SPRT" (more accurately, UDPSPRT) is the transport

protocol

and vxxx (based on ITU V.xxx) is the media format. We can create the following SDP equivalent to the T.38 case:

m=application 49345 udpsprt 100 a=sprtmap:100 vxxx/8000

Since SPRT can be used in non-MoIP contexts, it behooves us to separate SPRT attributes (protocol attributes) from vxxx attributes (media format attributes).

Does this seem to be a satisfactory analogy between the FoIP and MoIP layers? I would think that this would be clear as crystal if we invested the effort to examine extant IETF and ITU specifications.

Rajesh

| -----Original Message----- | From: Michael_Nicholas@3com.com [mailto:Michael_Nicholas@3com.com] | Sent: Friday, July 26, 2002 12:44 PM | To: fandreas@cisco.com | Cc: rkumar@cisco.com; bfoster@cisco.com; James_Renkel@3com.com; | tr301@tiacomm.org; tsg16q11@itu.int | Subject: Re: Multiple parameters on 'a' line: Please do help me | understand | | | | Flemming, | I believe the two questions are dependent on each other | (SDP representation vs whether MoIP is a Codec or Media type), so | Please provide us with said opinion and advice on SDP representation. | Thanks in advance, | Michael | | | I'm not on the e-mail reflectors and hence haven't followed all the | discussion, | so I'd rather not attempt an answer that is out of context. However, I | understand there is some controversy over the suggested SDP | representation | for | these things, and I'd be happy to provide an outside opinion and | advice on | that. | | -- Flemming | | Michael_Nicholas@3com.com wrote: | | > Flemming, | > Thank you for your previous comments. | > Your last note hints at the basis of our current discussion. | > Exactly what is V.moip? | > Is it a Codec type? Is it a Media type? Is it an Application? | > I'm not sure exactly how well you have been following V.moip | development, | > but I think we'd welcome an outside opinion on this. | > - Mike | > | > >> I think this question about the exact formatting of | parameters is less | > >> important than some of the other differences between the

proposals

| such | > as | > >> Codec declaration, the need or lack of need for capability sets, and | the | > >> number and numbering of UDP ports. | > >> | > > | > >I agree with that. Incidentally, I also agree that codecs should be | > declared | > >and there shouldn't be any unnecessary port restrictions. | > > | > >-- Flemming |