Subject: [MMUSIC] Updated draft: draft-garcia-mmusic-multiple-ptimes-problem-01.txt

From: "Willekens, Marc (NSN - BE/Belgium - MiniMD)" <[email-masked]>
Date: Mon, 19 Nov 2007 14:42:27 +0100

An updated internet-draft is available for the SDP "ptime" problem.
 
URL:
http://www.ietf.org/internet-drafts/draft-garcia-mmusic-multiple-ptimes-
problem-01.txt
 
The changes in version 01 are:
1. Description about different RFCs making references to the
ptime/maxptime related to definitions, recommendation, requirements,
default value.
2. An example of a problem case which can cause interworking problems.
3. Requirements as indicated at IETF.69.
4. A list of different solutions already proposed during the last years.

The IETF first wants to have a clear understanding of the problem and
the requirements before proposing a new standardized solution and/or
before making certain clarifications. So, people having trouble with the
ptime/maxptime now have the chance to indicate their problems and their
wishes for protocol improvements.
 
- Who really needs a ptime/maxptime in function of the codec for what
purpose?  
- What kind of interworking issues were encountered (e.g. during SIPit,
or during real-life deployments)?
- What kind of hardware limitations have you already encountered which
could not be solved with the existing standards?
- Who thinks a clarification can be sufficient?
- Is the problem only related to the interworking between ITU-IETF
world? If that's the case, is it then a problem for ITU or for IETF?
 
So, if you've any valuable information which could help to proceed with
this long-standing problem, please tell. 
The global VoIP community will appreciate it.
 
Thanks.

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

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 19 Nov 2007 13:42:59 -0600

Actually, there is another method.
 
Shouldn't we use "capability negotiation" for this?
 
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability

________________________________

From: Willekens, Marc (NSN - BE/Belgium - MiniMD) [mailto:[email-masked]] 
Sent: Monday, November 19, 2007 05:42
To: [email-masked]
Subject: [MMUSIC] Updated draft: draft-garcia-mmusic-multiple-ptimes-problem-01.txt

URL:
http://www.ietf.org/internet-drafts/draft-garcia-mmusic-multiple-ptimes-problem-01.txt
 
1. Description about different RFCs making references to the ptime/maxptime related to definitions, recommendation, requirements, default value.

The IETF first wants to have a clear understanding of the problem and the requirements before proposing a new standardized solution and/or before making certain clarifications. So, people having trouble with the ptime/maxptime now have the chance to indicate their problems and their wishes for protocol improvements.
 
- Who really needs a ptime/maxptime in function of the codec for what purpose?  
- What kind of interworking issues were encountered (e.g. during SIPit, or during real-life deployments)?
- What kind of hardware limitations have you already encountered which could not be solved with the existing standards?
- Who thinks a clarification can be sufficient?
- Is the problem only related to the interworking between ITU-IETF world? If that's the case, is it then a problem for ITU or for IETF?
 
So, if you've any valuable information which could help to proceed with this long-standing problem, please tell. 
The global VoIP community will appreciate it.
 
Thanks.

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Mon, 19 Nov 2007 13:33:31 -0800

It depends on the problem that you're trying to solve. If the problem
involves specifying a unique packetization period per media format, you
still need to standardize a multiple packetization period SDP attribute
such as PacketCable's "a=mptime" or "a=maxmptime" as defined in V.152.

Having said that, I agree that we should note (in
draft-garcia-mmusic-multiple-ptimes-problem) the SDP Capability
Negotiation syntax and semantics as it relates to the SDP "ptime"
problem. 

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Monday, November 19, 2007 1:43 PM
To: Willekens, Marc (NSN - BE/Belgium - MiniMD); [email-masked]
Cc: Flemming Andreasen (fandreas)
Subject: RE: [MMUSIC] Updateddraft:
draft-garcia-mmusic-multiple-ptimes-problem-01.txt

 

From: Willekens, Marc (NSN - BE/Belgium - MiniMD)
[mailto:[email-masked]]
Sent: Monday, November 19, 2007 05:42
To: [email-masked]
Subject: [MMUSIC] Updated draft:
draft-garcia-mmusic-multiple-ptimes-problem-01.txt

URL:

 

Thanks.

---

From: "Willekens, Marc (NSN - BE/Belgium - MiniMD)" <[email-masked]>
Date: Tue, 20 Nov 2007 02:11:12 +0100

Merci beaucoup François and Joe. I will also make a reference to the SDP capability negotiation in the next version.

But this is related to a possible solution space when multiple ptume or maxptime is required on a per codec basis.
But, is this a real requirement and who needs it? I've seen many different solution proposals during the last year, but what is the reason for a codec dependent ptime? That's something we want to figure out in the problem/requirement statement draft before looking into a possible solution. And when we need it, should it include a minumum and maximum value, a range with a certain granularity, etc...

So, if you've any information why this was done/needed by the PacketCable and ITU and why this is also needed in the IETF world, we are happy to hear it. 

Thanks,
Marc.

-----Original Message-----
From: ext Francois Audet [mailto:[email-masked]] 
Sent: maandag 19 november 2007 20:43
To: Willekens, Marc (NSN - BE/Belgium - MiniMD); [email-masked]
Cc: Flemming Andreasen
Subject: RE: [MMUSIC] Updated draft: draft-garcia-mmusic-multiple-ptimes-problem-01.txt

 

 
URL:

 

Thanks.

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Nov 2007 15:06:44 -0500

In the case of PacketCable, the reason is that the DOCSIS access network 
is a shared medium using time-slots. In order to transmit (in the 
upstream), you need to get a grant from the DOCSIS scheduler to do so. 
The grant is of a certain size and occurs at a certain point in time. 
For VoIP applications, you get QoS by reserving these grants ahead of 
time (at a particular frequency and with a given size). If you don't 
know the packetization period and resulting payload size needed ahead of 
time, you have a problem inasmuch as you either perform the wrong 
reservation, or you have to perform a worst-case reservation (least 
upper bound of the frequency and packet size for all the codecs in the 
media stream, which can be grossly inefficient). PacketCable solved that 
by specifying ptime on a per codec basis.

-- Flemming

---

From: "Willekens, Marc (NSN - BE/Belgium - MiniMD)" <[email-masked]>
Date: Tue, 27 Nov 2007 10:31:36 +0100

Hi Flemming,
Thanks for your comment. I will include this requirement in the next version of the ptime draft and in the slideset for Vancouver.

If I understand it correctly, the requirement for the multiple ptime for PacketCable comes from an optimalization of resource usage in a time-slot reservation system.
My question is: is this a static reservation during call setup, or can it also dynamically be changed during a call? What will happen when a VoIP terminal in the IETF world puts more voice frames in the RTP packet as was initially indicated in the SDP?

br,
Marc.

-----Original Message-----
From: ext Flemming Andreasen [mailto:[email-masked]] 
Sent: maandag 26 november 2007 21:07
To: Willekens, Marc (NSN - BE/Belgium - MiniMD)
Cc: ext Francois Audet; ext Joe Stone (joestone); [email-masked]
Subject: Re: [MMUSIC] Updated draft: draft-garcia-mmusic-multiple-ptimes-problem-01.txt

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 27 Nov 2007 23:26:51 -0500

> If I understand it correctly, the requirement for the multiple ptime for PacketCable comes from an optimalization of resource usage in a time-slot reservation system.
Correct.
> My question is: is this a static reservation during call setup, or can it also dynamically be changed during a call? 
It is done during call setup, but it may also be changed later on (e.g. 
in response to a codec renegotiation).
> What will happen when a VoIP terminal in the IETF world puts more voice frames in the RTP packet as was initially indicated in the SDP?
>   
If the IETF world is sending packets to the DOCSIS network, it won't be 
too bad, because the DOCSIS downstream behaves more like a tradional non 
time-slotted network. The upstream is the real problem from a QoS point 
of view (worst case, the packets will get dropped although typically 
they would receive best-effort treatment at the discretion of the 
service provider).

-- Flemming

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Wed, 28 Nov 2007 06:56:55 -0800

We should also point out that the reservation can be changed dynamically without explicit codec renegotiation. For example, in the case of V.152, both voice and voiceband data codecs are negotiated at call setup time. The "a=mptime" SDP attribute identifies a unique packetization period corresponding to each media format (codec). However, the initial reservation only reflects the voice codec and packetization period (as a matter of efficiency). Upon detecting fax, modem or text stimulus; or upon receiving a payload type previously negotiated as corresponding to voiceband data, the VoIP terminal (i.e., MTA) in the PacketCable world must dynamically change the reservation to reflect the voiceband data codec (possibly involving RFC 2198 redundancy) and packetization period. There is no renegotiation (e.g., SIP re-INVITE) at this point in the call. The VoIP terminal must know the voiceband data codecs and packetization periods at the time the call is established.
 
Joe

From: Flemming Andreasen (fandreas) 
Sent: Tuesday, November 27, 2007 10:27 PM
To: Willekens, Marc (NSN - BE/Belgium - MiniMD)
Cc: ext Francois Audet; Joe Stone (joestone); [email-masked]
Subject: Re: [MMUSIC] Updated draft: draft-garcia-mmusic-multiple-ptimes-problem-01.txt

	Hi Flemming,

Correct. 

It is done during call setup, but it may also be changed later on (e.g. in response to a codec renegotiation). 

If the IETF world is sending packets to the DOCSIS network, it won't be too bad, because the DOCSIS downstream behaves more like a tradional non time-slotted network. The upstream is the real problem from a QoS point of view (worst case, the packets will get dropped although typically they would receive best-effort treatment at the discretion of the service provider). 

-- Flemming 

	br,
	Marc.

	-----Original Message-----
	From: ext Flemming Andreasen [mailto:[email-masked]] 
	Sent: maandag 26 november 2007 21:07
	To: Willekens, Marc (NSN - BE/Belgium - MiniMD)
	Cc: ext Francois Audet; ext Joe Stone (joestone); [email-masked]
	Subject: Re: [MMUSIC] Updated draft: draft-garcia-mmusic-multiple-ptimes-problem-01.txt

	-- Flemming

		

		Thanks,
		Marc.
		
		-----Original Message-----
		From: ext Francois Audet [mailto:[email-masked]] 
		Sent: maandag 19 november 2007 20:43
		To: Willekens, Marc (NSN - BE/Belgium - MiniMD); [email-masked]
		Cc: Flemming Andreasen
		Subject: RE: [MMUSIC] Updated draft: draft-garcia-mmusic-multiple-ptimes-problem-01.txt

		 

		 
		URL:

		 

		Thanks.