Subject: [Speermint] Media requirements in draft-ietf-speermint-requirements-00

From: Gunnar Hellström <[email-masked]>
Date: Mon, 7 Aug 2006 22:08:36 +0100

There is a media section 3.3 in draft-ietf-speermint-requirements-00.txt

(http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-00.txt)

Currently it only specifies default audio codecs.

>From PSTN there is an important tradition to also carry real-time text as part of the telephony service.

Thus also for speermint, the default codec for real-time text should be supported.

The default codec mentioned in a number of other IETF specs is T.140, with RTP transport as dfefined in RFC 4103.

I suggest inserting a new bullet point in section 3.3

- the support of a compatible real-time text codec between communication peers; the
   T.140 transported as specified in RFC 4103 MUST be supported.

I do not see any reason to limit the specification to audio in VoIP. At least text and video should be included in this specification. 

Regards

Gunnar Hellström

[email-masked]

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 7 Aug 2006 14:47:16 -0700

Gunnar,

> I do not see any reason to limit the specification to audio in 

> VoIP. At least text and video should be included in this 

> specification.

This is an excellent point and let's hope the SPEERMINT EG will accept it.

Henry

________________________________

From: Gunnar Hellström [mailto:[email-masked]] 
Sent: Monday, August 07, 2006 2:09 PM
To: speermint
Subject: [Speermint] Media requirements indraft-ietf-speermint-requirements-00

(http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-00.txt <http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-00.txt> )

Regards

Gunnar Hellström

---

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 08 Aug 2006 14:53:45 +0200

> Thus also for speermint, the default codec for real-time text should be supported.

Well,

1)

currently the Introduction section says "... minimum set of requirements for
SIP-based _VoIP_ interconnection ..." (as well as the title).

If we add eg. text, video, etc. we'd probably also need to change this into
"... SIP-based multimedia interconnection ...".

2)

The text says those are "minimum" requirements. Anything that we shove into
that "minimum" as a MUST means that compliant implementations need to
implement this, thus reducing the number of compliant implementations.

I'll strongly vote to not bloat the "minimum requirements" - even more, i'd
try to keep those to the "very bare minimum requirements" wherever possible.

just my 2c

Alex

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Tue, 8 Aug 2006 09:18:00 -0400

I agree with Alex. Only some telephony applications carry real-time text. 

-----Original Message-----
From: Alexander Mayrhofer [mailto:[email-masked]] 
Sent: Tuesday, August 08, 2006 8:54 AM
To: Gunnar Hellström
Cc: speermint
Subject: Re: [Speermint] Media requirementsin draft-ietf-speermint-requirements-00

Well,

1)

2)

just my 2c

Alex

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 8 Aug 2006 09:33:38 -0400

Haven't we learned this lesson, and isn't the cost now low enough that we
can stop this argument?  Every place you have audio, you could have text,
either interactive or message based.

It's not unreasonable to require the interactive text codec be supported
across the spectrum of interconnects, so that people who can't hear can use
the systems we build.  In this context, supporting the text codec (as long
as there is only one to be concerned about, which is the case) everywhere
audio is supported is roughly zero cost in the peering system.  It costs
more to argue about it that it does to support it in the peering system.

You have a better chance at not specifying a minimal video codec, although
as I keep repeating, SPEERMINT is not intended to be the playground of soley
the video impaired crowd.  We need to recognize this.  Likewise minimum
codec for an IM peering exchange does not have audio in it.  I'm really
tired of people essentially saying "yes, yes, of course, but we REALLY know
this is for voice, that's where the money is".  Sorry, money or not, peering
is for text (including IM) and video, and any other media that comes on
through.  There cannot be a SPEERMINT specified minimum codec set unless it
is qualified like "if voice is supported at all, then at least ...."

Brian

> From: Pfautz, Penn L, GBLAM [mailto:[email-masked]]
> Sent: Tuesday, August 08, 2006 9:18 AM
> To: Alexander Mayrhofer; Gunnar Hellström
> Cc: speermint
> Subject: RE: [Speermint] Mediarequirementsin draft-ietf-speermint-
> requirements-00
>

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Tue, 8 Aug 2006 09:41:47 -0400

Brian:
Let me be clear. I'm not trying to exclude anything - and I don't think we should be in the business of specifying voice codecs either. Let us provide mechanisms for negotiation for supporting capabilities if providers want to make use of them but to think that Speermint is going to determine that all peering arrangements must support a particular media type is just kidding ourselves.

Penn

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, August 08, 2006 9:34 AM
To: Pfautz, Penn L, GBLAM; 'Alexander Mayrhofer'; 'Gunnar Hellström'
Cc: 'speermint'
Subject: RE: [Speermint] Mediarequirementsin draft-ietf-speermint-requirements-00

Brian

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 8 Aug 2006 16:05:22 +0100

Explicitly including some codecs can become a very healthy harmonizing
factor, increasing the opportunity to get media through.

RFC 4504 "Sip Telephony device requirements" has made a good effort to list
essential codecs etc.. Supporting them through peering arrangements would
mean that terminal and network developments are in line.

RFC 4504 specifies RFC 4103 for real-time text. It would be pointless to
recommend it for terminals if inter-operator connections will not guarantee
to carry it.

Real-time text should be seen as a part of VoIP.

Video belongs to Multimedia Telephony, also including audio and real-time
text. It is reasonable to expect the peering arrangements to also support
Multimedia Telephony, but that would certainly require either a new spec or
a title and scope change. So if there is a reason to specify for VoIP,
please go ahead with audio and real-time text.

Gunnar

-----Original Message-----
From: Pfautz, Penn L, GBLAM [mailto:[email-masked]]
Sent: Tuesday, August 08, 2006 2:42 PM
To: Brian Rosen; Alexander Mayrhofer; Gunnar Hellström
Cc: speermint
Subject: RE: [Speermint] Mediarequirementsin
draft-ietf-speermint-requirements-00

Brian:
Let me be clear. I'm not trying to exclude anything - and I don't think we
should be in the business of specifying voice codecs either. Let us provide
mechanisms for negotiation for supporting capabilities if providers want to
make use of them but to think that Speermint is going to determine that all
peering arrangements must support a particular media type is just kidding
ourselves.

Penn

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, August 08, 2006 9:34 AM
To: Pfautz, Penn L, GBLAM; 'Alexander Mayrhofer'; 'Gunnar Hellström'
Cc: 'speermint'
Subject: RE: [Speermint] Mediarequirementsin
draft-ietf-speermint-requirements-00

Brian

---

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 08 Aug 2006 18:33:39 +0200

> factor, increasing the opportunity to get media through.

What do you mean by requiring certain codecs? Does that mean that:

- the peer does not filter out the respective SDP line?
- the peer is obliged to force his customers supporting the codec? (by which
mechanism, btw? "codec police"?)
- that the peer MUST provide transcoding on behalf of the client for that
codec (and then, from what to what?)

Perhaps we're talking about different issues here. My point is that if you
_require_ a VoIP peer to support eg. real time text, and this peer is an
"open" peer ("open" in terms that he allows his customers to choose their
own equipment, endpoints, etc. and media streams run end to end), there
would be almost certainly be an endpoint which does _not_ support that codec.

Would that mean that such a peer would then not be compliant, because one of
his customers does not support the REQUIRED codec? I can't imagine that's
the intent.

What about saying something like "Peers SHOULD NOT artificially limit the
set of codecs on behalf of their clients. In case the peer provides
transcoding services, the following codecs MUST be supported: ..."?

BTW, "codecs" is not just the algorithm... the next rathole is "media packet
sizes" (30ms packets anyone? :) Do we want to go down there?

cheers

alex

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 8 Aug 2006 13:08:13 -0400

> Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint-
> requirements-00
> 
> Gunnar Hellström wrote:
[[Reinaldo]] 

I think we are forgetting the business aspect here.

Are there such ISPs in Europe that allow you to choose whatever equipment you like and still support your installation? (This is a legitimate question). I haven't lived in Europe long enough to notice these things. 

In the US when you buy DSL or Cable service you receive the modem by mail. You can choose your modem but it has to be on a list of supported modems, otherwise you are on your own. I cannot imagine an ISP supporting any end device/modem/phone, it would be a money black hole. 

I believe the real issue is at (or near) the peering point where you will have to possibly perform transcoding.

> the intent

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 8 Aug 2006 15:42:46 -0700

> BTW, "codecs" is not just the algorithm... the next rathole is "media 
> packet sizes" (30ms packets anyone? :) Do we want to go down there?

Default codecs are not a rat hole. 
Signaling standards for peering without media defaults are meaningless.

Thanks, Henry

-----Original Message-----
From: Alexander Mayrhofer [mailto:[email-masked]] 
Sent: Tuesday, August 08, 2006 9:34 AM
To: Gunnar Hellström
Cc: speermint
Subject: Re: [Speermint]Mediarequirementsin draft-ietf-speermint-requirements-00

cheers

alex

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 8 Aug 2006 21:48:53 +0100

This wording seems good to me:
>"Peers SHOULD NOT artificially limit the

> codec (and then, from what to what?)

I think it is the following:
- the peer does not filter out the respective SDP line, convey the
negotiation of a list of codecs and support transfer of their packets.
> - that the peer MUST provide transcoding on behalf of the client for a
specified list of codec pairs. ( A list of externally supported versus
internally supported codecs).

Example:
You want to set up operations with terminals ONLY supporting ILBC audio, RFC
4103 text and H.264 video.
You set up your peering conditions to:

Supported through:
ilbc
rfc4103
h.264

Transcoding:
external<>internal
   G.711<>ilbc
   G.722<>ilbc
   h.263<>h.264

What should be specified in a peering requirement spec is the minimal sum of
the "supported through" and the external side of the transcoded pairs.

That makes it possible for you to operate your network with cleanly
specified terminals and
still your customers may have calls with various kinds of terminals in
peering networks in an ordered way.

Agree?

ANother dimension is to what degree you support passthrough of additional
features as RFC 2833 DTMF transmission, redundancy or FEC coding and
correction, hop-by-hop security methods, QOS etc.

Gunnar
----------------------------------------------------------------------------
-
Gunnar Hellström, Omnitor
[email-masked]
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Tuesday, August 08, 2006 6:08 PM
To: Alexander Mayrhofer; Gunnar Hellström
Cc: speermint
Subject: RE: [Speermint]Mediarequirementsin

[[Reinaldo]]

Are there such ISPs in Europe that allow you to choose whatever equipment
you like and still support your installation? (This is a legitimate
question). I haven't lived in Europe long enough to notice these things.

In the US when you buy DSL or Cable service you receive the modem by mail.
You can choose your modem but it has to be on a list of supported modems,
otherwise you are on your own. I cannot imagine an ISP supporting any end
device/modem/phone, it would be a money black hole.

I believe the real issue is at (or near) the peering point where you will
have to possibly perform transcoding.

> packet

---

From: Klaus Darilion <[email-masked]>
Date: Wed, 09 Aug 2006 14:31:56 +0200

Reinaldo Penno wrote:
> Are there such ISPs in Europe that allow you to choose whatever
> equipment you like and still support your installation? (This is a
> legitimate question). I haven't lived in Europe long enough to notice
> these things.

Yes, there are such ISPs. You get your SIP provisioning data and can use 
any SIP client.

regards
klaus

> 
> In the US when you buy DSL or Cable service you receive the modem by
> mail. You can choose your modem but it has to be on a list of
> supported modems, otherwise you are on your own. I cannot imagine an
> ISP supporting any end device/modem/phone, it would be a money black
> hole.
> 
> I believe the real issue is at (or near) the peering point where you
> will have to possibly perform transcoding.
> 
> 
>> Would that mean that such a peer would then not be compliant,
>> because one of his customers does not support the REQUIRED codec? I
>> can't imagine that's the intent
>> 
>> What about saying something like "Peers SHOULD NOT artificially
>> limit the set of codecs on behalf of their clients. In case the
>> peer provides transcoding services, the following codecs MUST be
>> supported: ..."?
>> 
>> BTW, "codecs" is not just the algorithm... the next rathole is
>> "media packet sizes" (30ms packets anyone? :) Do we want to go down
>> there?
>> 
>> cheers
>> 
>> alex
>> 
>> _______________________________________________ Speermint mailing
>> list [email-masked] 
> _______________________________________________ Speermint mailing
> list [email-masked]

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 9 Aug 2006 08:37:15 -0400

Do they guarantee universal call completion? By that I mean, can you make a call to anywhere and send/receive media? Do they perform transcoding to achieve that?

> From: Klaus Darilion [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2006 5:32 AM
> To: Reinaldo Penno
> Cc: Alexander Mayrhofer; Gunnar Hellström; speermint

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 9 Aug 2006 14:38:25 +0100

I know ISP:s who enable SIP calls anywhere, but not with any transcoding.

Gunnar

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Wednesday, August 09, 2006 1:37 PM
To: Klaus Darilion
Cc: Alexander Mayrhofer; Gunnar Hellström; speermint
Subject: RE: [Speermint]Mediarequirementsin

Do they guarantee universal call completion? By that I mean, can you make a
call to anywhere and send/receive media? Do they perform transcoding to
achieve that?

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 9 Aug 2006 09:48:11 -0400

Hello Gunnar,

Not sure I follow your explanation. Is there a website for such ISP(s) that allows a user to use any SIP endpoint and guarantee call completion across the planet? I'm really curious on how they opearate...

Thanks,

Reinaldo

> Sent: Wednesday, August 09, 2006 6:38 AM
> To: Reinaldo Penno; Klaus Darilion
> Cc: Alexander Mayrhofer; speermint
> Subject: RE: [Speermint]Mediarequirementsin draft-ietf-speermint-
> requirements-00
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Aug 2006 09:48:50 -0400

One thing that may inform this discussion is that it's been common that
requirements for emergency calls (1-1-2/9-1-1/...) often end up driving
requirements elsewhere in telecommunications systems.  We're doing some work
in ecrit on support of emergency calls on the Internet, and the subject of
codecs is in discussion there.  

Looks like (no decisions yet) we WILL have a short list of codecs that end
up being MUST IMPLEMENT on phones (at least one of) and PSAPs (all of).
SPEERMINT could reference that document, which will be a BCP.  Clearly, the
problem there is acute; you must have a compatible codec between a caller
and the emergency center if you are to be able to get help.  It could be
that such a list ends up being MUST only for g.711 (at least A, probably
mu), and SHOULD for things like AMR, EvRC, iLBC, and possibly g.729 as well
as AMR-WB and some form of g.722.

Brian

> Sent: Wednesday, August 09, 2006 8:37 AM
> To: Klaus Darilion
> Cc: speermint
> Do they guarantee universal call completion? By that I mean, can you make
> a call to anywhere and send/receive media? Do they perform transcoding to
> achieve that?
> 
> 
>

---

From: Klaus Darilion <[email-masked]>
Date: Wed, 09 Aug 2006 17:51:27 +0200

It is like in the email world. If you use a standard compliant email 
client, email will work, regards what is your client and regardless who 
is the provider.

Of course these service providers do not guarantee that the service will 
work when using non-supported SIP clients, but if you use a compliant 
SIP client, it will work.

regards
klaus

Reinaldo Penno wrote:
>> a

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 09 Aug 2006 18:05:23 +0200

> as AMR-WB and some form of g.722.

Emergency calls are probably a good tool to drive actual deployment. No
vendor wants bad press about fatalaties because of failed codec negotiation.

Re-using such work sounds definitely like a good idea to me, at least we
should coordinate on that. Anything else that could be re-used from there?

cheers

alex

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Aug 2006 13:42:23 -0400

Well, maybe.  The draft (currently draft-rosen-ecrit-phonebcp-01) says a lot
of things that phones and proxies must do to support emergency calls.  It
provides a baseline of capabilities you can count on.  Look at the draft.

Brian

> Sent: Wednesday, August 09, 2006 12:05 PM
> To: Brian Rosen
> Cc: 'Reinaldo Penno'; 'Klaus Darilion'; 'speermint'

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 9 Aug 2006 17:07:08 -0400

I'm sorry, the whole point that somebody made before is that you could use _any_ client and things you would work. If now you are saying that you need to use a compliant client, then that's just like other carriers. 

> Sent: Wednesday, August 09, 2006 8:51 AM
> To: Reinaldo Penno
> Cc: Gunnar Hellström; Alexander Mayrhofer; speermint
> > Not sure I follow your explanation. Is there a website for such ISP(s)
> that allows a user to use any SIP endpoint and guarantee call completion
> across the planet? I'm really curious on how they opearate...
> >
> > Thanks,
> >
> > Reinaldo
> >