Subject: RE: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-00.t xt

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 23 Jun 2006 15:21:57 +0100

Section 3.5 indicates:

   The minimum requirements to allow a successful VoIP interconnection
   include:

   o  the mandatory support of RTP *and* RTCP as defined in [RFC3550],

   o  the support of compatible codecs between communication peers, the
      G.711 MUST be supported, the IETF iLBC [RFC3951] codec and its RTP
      payload format [RFC3952] SHOULD be supported.

   o  the support of the VoIP metric block as defined in RTP Control
      Protocol Extended Reports [RFC3611] MAY be supported.

What exactly does this mean to the two bodies that are making the peering arrangement. Is this a requirement to control the codecs used by the UAs attached to the peering organisations equipment before peering can occur, or a requirement to support transcoding if these requirements are not met by the population of attached UAs.

Additional nit comment. RFC 2327 is obsolete and sdp-new is imminently about to be published and I assume we are going to reference that document (it will be RFC 4566).

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 21 June 2006 23:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Speermint] I-D 
> ACTION:draft-ietf-speermint-requirements-00.txt
> 
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Session PEERing for 
> Multimedia INTerconnect Working Group of the IETF.
> 
> 	Title		: SPEERMINT Requirements for SIP-based 
> VoIP Interconnection
> 	Author(s)	: J. Mule
> 	Filename	: draft-ietf-speermint-requirements-00.txt
> 	Pages		: 10
> 	Date		: 2006-6-21
> 	
>    This document describes general requirements for Session 
> PEERing for
>    Multimedia INTerconnect and defines the minimum set of requirements
>    applicable to SIP session peering for VoIP interconnects.
> 
>    In its current form, the document is a first draft based on the
>    SPEERMINT mailing list's discussions on requirements.  The main
>    objectives are to generate consensus on what categories of
>    requirements should be covered, and to start more 
> discussions on the
>    technical protocol requirements that apply to VoIP interconnects.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-speermint-requi
rements-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-speermint-requirements-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-requirements-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 26 Jun 2006 14:19:44 -0400

Rohan,

Agree with your codec point.  I was indirectly pushing that out as being
just another policy element.

You are missing what I am promoting.  I want "federation" to be a
protocol element, so you can map domains to federations.  Being able to
learn such associations in DNS will enable two parties to determine if
they "speak" the same federation dialect, i.e. can route SIP directly or
not.

Mike 

> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: Sunday, June 25, 2006 2:41 PM
> To: Michael Hammer (mhammer)
> Cc: Drage, Keith (Keith); [email-masked]
> Subject: Re: [Speermint] I-D 
> ACTION:draft-ietf-speermint-requirements-00.t xt
> 
> Mike,
> 
> There is no requirement for a federation to exist in 
> speermint.  It might or it might not, but the IETF won't be 
> very effective trying to put requirements on something which 
> is effectively a business arrangement.  We can define a set 
> of protocols however, which needs to be useful in the big-I 
> Internet and hopefully for folks building federations and 
> other clubs as well.
> 
> Everyone,
> 
> I think codec selection should be out of scope.  Mandating 
> G.711 will have no positive effect now.  Everyone supports it 
> today in some way or another, but it could be detrimental in 
> the future.  The point of the SDP negotiation is to allow RTP 
> *endpoints* to select the best codec in common under the 
> circumstances.  I don't think we can do any better than that 
> in a requirements document, especially since we are 
> describing an interface between SIP intermediaries that I 
> hope will not even be a participant in the RTP media most of the time.
> 
> thanks,
> -rohan
> 
> 
> 
> On 6/23/06, Michael Hammer (mhammer) <[email-masked]> wrote:
> > Shouldn't the requirement be that the policy of a federation should 
> > address the default codecs used by a federation to interconnect?
> >
> > Mike
> >
> >
> > > From: Drage, Keith (Keith) [mailto:[email-masked]]
> > > Sent: Friday, June 23, 2006 10:22 AM
> > > To: [email-masked]
> > > Subject: RE: [Speermint] I-D
> > > ACTION:draft-ietf-speermint-requirements-00.t xt
> > >
> > > Section 3.5 indicates:
> > >
> > >    o  the support of compatible codecs between 
> communication peers, 
> > > the
> > >       G.711 MUST be supported, the IETF iLBC [RFC3951] 
> codec and its 
> > > RTP
> > > What exactly does this mean to the two bodies that are making the 
> > > peering arrangement. Is this a requirement to control the codecs 
> > > used by the UAs attached to the peering organisations equipment 
> > > before peering can occur, or a requirement to support 
> transcoding if 
> > > these requirements are not met by the population of attached UAs.
> > >
> > > Additional nit comment. RFC 2327 is obsolete and sdp-new is 
> > > imminently about to be published and I assume we are going to 
> > > reference that document (it will be RFC 4566).
> > >
> > > regards
> > >
> > > Keith
> > >
> > > > This draft is a work item of the Session PEERing for Multimedia 
> > > > INTerconnect Working Group of the IETF.
> > > >
> discussions 
> > > > on the
> > > [email-masked] with the word unsubscribe 
> in the body 
> > > of the message.
> > > You can also visit 
> > > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > Internet-Drafts are also available by anonymous FTP. 
> Login with the 
> > > username "anonymous" and a password of your e-mail address. After 
> > > logging in, type "cd internet-drafts" and then
> > > http://www.ietf.org/shadow.html or 
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > >       "FILE
> > > /internet-drafts/draft-ietf-speermint-requirements-00.txt".
> > >
> > >       a MIME-compliant mail reader.  Different 
> MIME-compliant mail 
> > > readers

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 27 Jun 2006 11:23:36 -0400

My initial thought is that you are accurate saying that federations are
NOT REQUIRED for speermint.  Federations MAY or MAY NOT be used, as you
noted, and to that extent will be considered in some fashion here.

As for codecs, I think we'll have to see based on further WG discussion.
I would surely agree that codec negotiation / selection is *well*
handled in the underlying SIP protocol itself.  However, we may well
find a need to specify (or not) a lowest common denominator codec but
we'll have to see how our requirements work progress.

Jason

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 27 Jun 2006 15:02:30 -0400

IFF you are not interested in global rechability of users, then yes
small pockets of users can connect without federations, or whatever name
you want to give it.  However, if you want global scalability, something
other than a full mesh is needed, and that implies some degree of
hierarchy.  Call that grouping mechanism what you want, it is needed.

If the value of the PSTN is 4 billion squared, I would prefer the SIP
NGN network of the future to be at least as valuable.

Mike

> From: Livingood, Jason [mailto:[email-masked]] 
> Sent: Tuesday, June 27, 2006 11:24 AM
> To: Rohan Mahy; Michael Hammer (mhammer)
> Cc: [email-masked]
> My initial thought is that you are accurate saying that 
> federations are NOT REQUIRED for speermint.  Federations MAY 
> or MAY NOT be used, as you noted, and to that extent will be 
> considered in some fashion here.
> 
> I would surely agree that codec negotiation / selection is 
> *well* handled in the underlying SIP protocol itself.  
> However, we may well find a need to specify (or not) a lowest 
> common denominator codec but we'll have to see how our 
> requirements work progress.
> 
> Jason
> 
> > There is no requirement for a federation to exist in speermint.  It 
> > might or it might not, but the IETF won't be very effective 
> trying to 
> > put requirements on something which is effectively a business 
> > arrangement.  We can define a set of protocols however, 
> which needs to 
> > be useful in the big-I Internet and hopefully for folks building 
> > federations and other clubs as well.
> > 
> > Everyone,
> > 
> > G.711 will have no positive effect now.  Everyone supports 
> it today in 
> > some way or another, but it could be detrimental in the 
> future.  The 
> > point of the SDP negotiation is to allow RTP
> > circumstances.  I don't think we can do any better than that in a 
> > requirements document, especially since we are describing 
> an interface 
> > between SIP intermediaries that I hope will not even be a 
> participant 
> > in the RTP media most of the time.
> > 
> > thanks,
> > -rohan
> > 
> > 
> >

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 27 Jun 2006 14:16:31 -0600

Keith wrote:
> peering arrangement. Is this a requirement to control the codecs used
> by the UAs attached to the peering organisations equipment before
> peering can occur, or a requirement to support transcoding if these
> requirements are not met by the population of attached UAs.
Up for debate, but the later is more inline with a generic requirement
draft. 

> Additional nit comment. RFC 2327 is obsolete and sdp-new is imminently
> about to be published and I assume we are going to reference that
> document (it will be RFC 4566).
Ok - will update the reference.

Thank you,
Jean-Francois.

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 27 Jun 2006 14:24:17 -0600

Rohan wrote:
> Everyone,
>
> I think codec selection should be out of scope.  Mandating G.711 will
> have no positive effect now.  Everyone supports it today in some way
> or another, but it could be detrimental in the future.  The point of
> the SDP negotiation is to allow RTP *endpoints* to select the best
> codec in common under the circumstances.  I don't think we can do any
> better than that in a requirements document, especially since we are
> describing an interface between SIP intermediaries that I hope will
> not even be a participant in the RTP media most of the time.

This ID is for a set of *minimum* requirements for VoIP interconnect. I
have never walked in a meeting related to VoIP interop between 2 systems
or operators without having cleared the voice codec part (or assumed
G.711 is there).

I also note that it is in scope of the SIP Forum's use case for IP-PBX
to VSP VoIP interconnect.

Jean-Francois.

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 28 Jun 2006 09:27:47 -0400

Folks:

The bottom line of the support of codec is this: Support of QOS for the
VoIP application.

For example, one can do transcoding, but will they meet QOS
requirements? 

It is not simply the bandwidth. It is also about end-to-end delay,
jitter, and packet loss at the VoIP presentation layer (beyond IP
network layer).

Best regards,
Radhika R. Roy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stastny Richard
Sent: Wednesday, June 28, 2006 7:06 AM
To: Livingood, Jason
Cc: [email-masked]
Subject: RE: [Speermint] I-D
ACTION:draft-ietf-speermint-requirements-00.t xt

Jason wrote:
> 
> So in the case of voice, the question at hand is - is there a lowest
> common denominator voice codec which should be required to do peering?
> If not, is there much utility in peering if certain provider types
> cannot agree on a common codec?
> 
The codecs are a terminal or end-user device issue. Peering between
service 
providers have no influence on these. So if there is no match in
available 
codecs, the only way out is to insert a transcoding function on one or
on both sides.

Since I am not so in protocol details, so I have a question: is there a
call
flow available to do so?

And if, the codec selected is part of the peering agreement itself.
Which 
codec is up to the parties.

Richard

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 28 Jun 2006 11:14:33 -0400

I do not disagree with the fact that codec mismatches are a general
technology issue.  

However, I am not yet convinced (I'd like some operators to weigh in)
that continuing to *discuss* whether or not there *may* be a need for a
lowest common demoninator codec requirement is necessarily bad. 

Yes, endpoints or other elements will negotiate codecs, and no we're not
trying to tread into that area.  But I do think it's rational to
consider whether many peered domains may find it in their interest to
have a common codec, or language, to fall back on failing other, perhaps
more preferred or efficient codecs.  Whether someone had to transcode in
their network to meet such a requirement, were it even adopted, would be
out of scope as much as how the internals of IMS, PacketCable, and
washing machines are to us.  ;-)

Again, looking to have some operators weigh in with their thoughts.

Jason

> From: Patrick Melampy [mailto:[email-masked]] 
> Sent: Wednesday, June 28, 2006 10:44 AM
> To: Livingood, Jason
> Cc: [email-masked]
> If there are 3 carriers...A, B, and C
> 
> A may only support AMR (wireless network) B may support AMR 
> and G.711 (wireless interconnect network) C may only support 
> G.711 (terminating PSNT network)
> 
> So now we have a problem...
> 
> A-----B  (negotiates to AMR) WORKS
> 
> B-----C  (negotiates to G.711) WORKS
> 
> But A----via B-----C  FAILS [has no agreeable CODEC's]
> 
> Thus B finds that on a call by call basis, if they support A 
> and C, they may not be able to provide universal connectivity 
> from A to C and vica-versa.
> 
> I don't see how this problem can be avoided when there are 3 
> or more carriers interconnected. I would suggest that this 
> problem is outside the scope of spearmint, and just a general problem.
> 
> I don't think we should require a codec (this doesn't always 
> make sense), nor do I think we should require transcoding 
> which is offensive in its own rite. I just think this is part 
> of the internal problem B has with the services B wishes to 
> offer. B may have to provide either segmented service 
> offerings, and or transcoding internal to its network to 
> support A and C peering relationships.
> 
> Said another way, I do not believe incompatible CODEC's is a 
> service provider peering issue, but rather a general 
> technology issue that exists with or without service provider borders.
> 
> 
> Sent: Wednesday, June 28, 2006 6:46 AM
> To: Brian Rosen; Jean-Francois Mule; Drage, Keith (Keith); 
> Rohan Mahy; Michael Hammer (mhammer)
> Cc: [email-masked]
> Let's drop the IM and video examples -- for now.  Let's first 
> focus on getting the basic one working that we're committed 
> to: voice.  
> 
> So in the case of voice, the question at hand is - is there a 
> lowest common denominator voice codec which should be 
> required to do peering?
> If not, is there much utility in peering if certain provider 
> types cannot agree on a common codec?
> 
> Jason
> 
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Tuesday, June 27, 2006 5:40 PM
> > To: 'Jean-Francois Mule'; 'Drage, Keith (Keith)'; Livingood, Jason; 
> > 'Rohan Mahy'; 'Michael Hammer (mhammer)'
> > Cc: [email-masked]
> > Consider an all-IMS, all-GSM federation.  Do they have to 
> have G.711?
> > 
> > Consider an all-video conference federation.  Do they have to have 
> > G.711?
> > 
> > Consider an all-IM federation.  Do they have to have G.711?
> > 
> > 
> > Brian
> > 
> > From: Jean-Francois Mule [mailto:[email-masked]]
> > Sent: Tuesday, June 27, 2006 4:30 PM
> > To: Drage, Keith (Keith); Livingood, Jason; Rohan Mahy; 
> Michael Hammer
> > (mhammer)
> > Cc: [email-masked]
> > So is this kind of scenario in scope of speermint?
> > Take:
> > 	- on one side, a 3GPP IMS network with the typical UE 
> that does not 
> > support G.711 on the terminal, and,
> > 	- on the other, a VSP like free world dialup or alike 
> that allow any 
> > sip UA with any kind of codec.
> > 
> > Do we want to have some minimal requirements to ensure that 
> > negotiation just does not fail?  I could care less where this 
> > transcoding function is implemented.
> > 
> > Jean-Francois
> > 
> > > Sent: Tuesday, June 27, 2006 11:31 AM
> > > To: Livingood, Jason; Rohan Mahy; Michael Hammer (mhammer)
> > > Cc: [email-masked]
> > > But this still does not answer my original question.
> > > 
> > > How can you mandate a codec for what is essentially a
> > network operator
> > > when that operator does not own the terminals (which
> > contain the vast
> > > majority of the codecs). Are you making a requirement for
> > transcoding
> > > support in the absence of whatever codec set is defined, or
> > is it just
> > > an empty letter?
> > > 
> > > regards
> > > 
> > > Keith
> > > 
> > > > From: Livingood, Jason 
> [mailto:[email-masked]]
> > > > Sent: 27 June 2006 16:24
> > federations
> > > > are NOT REQUIRED for speermint.  Federations MAY or MAY
> > NOT be used,
> > > > as you noted, and to that extent will be considered in
> > some fashion
> > > > here.
> > > >
> > > > find a need to specify (or not) a lowest common 
> denominator codec
> > > but
> > speermint.  
> > > > > It might or it might not, but the IETF won't be very 
> effective 
> > > > > trying to put requirements on something which is 
> effectively a 
> > > > > business arrangement.  We can define a set of protocols
> > however,
> > > > > which needs to be useful in the big-I Internet and
> > hopefully for
> > > > > folks building federations and other clubs as well.
> > > > >
> > > > > Everyone,
> > > > >
> > > > > today in some way or another, but it could be
> > detrimental in the
> > > > > future.  The point of the SDP negotiation is to allow RTP
> > > > > requirements document, especially since we are describing an 
> > > > > interface between SIP intermediaries that I hope will
> > not even be
> > > > > a participant in the RTP media most
> > > > of the time.
> > > > >
> > > > > thanks,
> > > > > -rohan
> > > > >
> > > > >
> > > > >
> > > > > > >    o  the mandatory support of RTP *and* RTCP as 
> defined in 
> > > > > > > [RFC3550],
> > > > > > >
> > > > > > > >    Multimedia INTerconnect and defines the 
> minimum set of
> > > > > > > requirements
> > > > > > > >    objectives are to generate consensus on what 
> categories
> > > of