Subject: RE: [MMUSIC] sdp alt, alt-default-id and alt-group

From: "Gamze Seckin" <[email-masked]>
Date: Thu, 6 Nov 2003 11:11:07 -0800

Hi Magnus,

Thanks. I do not see bugs and I think this proposal could be useful actually.
But I also think it is important that IETF takes into account these sections somehow, since they may have an impact on several proposals, say such as transport independent bw modifiers?

br
g

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Thursday, November 06, 2003 10:34 AM
To: Gamze Seckin
Cc: [email-masked]
Subject: Re: [MMUSIC] sdp alt, alt-default-id and alt-group

Hi Gamze,

No there are no IETF pointers about this proposal. This work is totally 
created within the 3GPP SA4. There should probably have been some review 
  by the IETF before the acceptance of the proposal, but that has not 
happened. However as the Release 6 has not been approved yet, any bugs 
in this proposal can still be fixed.

If you are interested in this proposal please review chapter 5.3.3.3. 
and  5.3.3.4 in the 3GPP TS 26.234 version 0.3.0 of Release 6 
specification, which can be downloaded here:

http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/S4-030680.zip

This is a 200 kb zipped word document.

Cheers

Magnus

Gamze Seckin wrote:

> Dear mmusic members,
> 
> my apologies if this is discussed here before:
> 
> I am looking for ietf pointers (if there are any) on the sdp descriptions provided in http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/ document s4-30680.
> on sdp "alt" and "alt-default-id" attributes and the session level grouping attribute, "alt-group".
> 
> best regards
> g
> 
> 
> 
> -----------------------------------------------------------
> Gamze Seckin, Ph.D.
> Director of Research
> Vidiator Technology (US) Inc.
> 411 108th Avenue NE. Suite 688
> Bellevue, WA 98004 USA.
> www.vidiator.com
> 
> Phone: 1.425.688.8811x2108
> Email: [email-masked]
> 
> This e-mail message (including any attachment) is intended only for the personal use of the recipient(s) named above. This message is confidential and may be legally privileged. If you are not an intended recipient, you may not review, copy or distribute this message. If you have received this communication in error, please notify us immediately by e-mail and delete the original message. Any views or opinions expressed in this message are those of the author only. Furthermore, this message including any attachment does not create any legally binding rights or obligations whatsoever, which may only be created by the exchange of hard copy documents signed by a duly authorized representative of Vidiator Technology (US) Inc.
> -----------------------------------------------------------
> 
> 
> -----Original Message-----
> From: Geetha Srikantan [mailto:[email-masked]]
> Sent: Wednesday, November 05, 2003 10:55 AM
> To: Magnus Westerlund
> Cc: Enrico Balatti; [email-masked]
> Subject: Re: [MMUSIC] RTSP transport negotiation
> 
> 
> 
> hi Magnus,
> 
> Yes, it looks like we can drop the Range header from SETUP request.
> We probably want the Range header + RTP-Info in the SETUP response
> for VOD streams...with the caveat that packets can be lost during the
> switch. 
> 
> I don't believe all components of the RTP-Info header are relevant for
> live streams that are 'reflected' by the server - here the server acts
> as a translator. The RTP stream url is known, however the exact sequence
> number and timestamp for RTP packets is determined by the source of the
> live stream, not the server reflecting the stream. Hence, I recommend
> that the RTP-Info carry no sequence number or rtptime for live streams.
> 
> Also, I noticed that the RTP spec requires change of SSRC when the
> transport changes. This needs to be added to the transport negotiation 
> notes.
> 
> I will update the notes and send it to the alias.
> 
> geetha
> 
> 
> On Wed, 2003-11-05 at 03:23, Magnus Westerlund wrote:
> 
>>Hi Geetha,
>>
>>Thanks for your views. Comments inline
>>
>>Geetha Srikantan wrote:
>>
>>>hi Magnus,
>>>
>>>My assumption was that SETUP during play happens *after* the client has
>>>switched to the new transport..synchronization is an issue in this case.
>>>I agree that if we can assume that the client requests new transport
>>>before switching to the new transport, there is probably no
>>>synchronization issue. I have two follow-up questions on this:
>>>
>>
>>Yes, I would also think that in most cases the application will not know 
>>about the change of transport until it actually happens. This will 
>>probably result in the loss of some media packets. This loss can be 
>>dealt with in a few different way depending on the what the application 
>>can use: media level retransmission, RTSP go back through PAUSE and PLAY.
>>
>>However in regards the question about what your assumption are and why 
>>you need Range in the request I think your answer clearly points out 
>>that there are no need for Range in the Request. There seem to be 
>>reasons for it to be allowed in the Response, to indicate the correct 
>>new synchronization after the change of address.
>>
>>So are you still seeing any need for Range in the SETUP request? If that 
>>can be motivated I definitely think there will be possibility to change 
>>the specification to allow for this. However this would need further 
>>investigation.
>>
>>
>>
>>>a) How does a mobile client get notified about new transports - such as 
>>>   a new IP address?  How far ahead of time does the client get
>>>   notified?
>>
>>I would say that this is not a question we can answer. I think we simply 
>>need to ensure that the solution works with both sufficient notification 
>>and without. However without overlap in transport availability, there 
>>will be losses of media packets.
>>
>>
>>
>>>b) What is the range of time over which the transport switch happens?
>>>   Consider a scenario where the client requests an IP address change
>>>   for example, via SETUP with no Range, and the server starts sending
>>>   packets to the new IP. Is there a chance that the buffers at the new
>>>   IP get overrun, before the client switches to the new IP?
>>>   It would help if the network guarantees that the transport switch
>>>   will not lose any packets due to buffer overflows,
>>>   
>>
>>As I have stated prior I think we must require the client to have access 
>>to an interface it sends traffic to. If there is overlap I would assume 
>>that it can receive data on both during this period. I don't find it 
>>reasonable to get any guarantees from the networks. I would assume that 
>>any switch of network depends on the change of access technology, for 
>>example by switching from cable to WLAN or to 3G mobile network. The 
>>probability that there will exist any mobility functionality between 
>>these networks seems very small.
>>
>>I think that we should design our solution to allow the mobility, only 
>>note that it may loss some packets
>>
>>Cheers
>>
>>
>>Magnus Westerlund
>>
>>Multimedia Technologies, Ericsson Research EAB/TVA/A
>>----------------------------------------------------------------------
>>Ericsson AB                | Phone +46 8 4048287
>>Torshamsgatan 23           | Fax   +46 8 7575550
>>S-164 80 Stockholm, Sweden | mailto: [email-masked]
>>
>>
>>_______________________________________________
>>mmusic mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/mmusic

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Nov 2003 14:55:39 -0500

Well, I've not seen the 3gpp docs, but there is an alt SDP parameter 
defined in ICE:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt

Is this the same as what is being used by 3gpp? If not, we have a 
serious name collision...

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 07 Nov 2003 12:40:57 +0100

Hi Jonathan,

Yes, we have a collision in the name space. I detected it yesterday when 
I read ICE. However as I understand your proposal for "alt" is brand 
new. The 3GPP "alt" has been there for a while as being accepted 
solution and included in the specification. However as it isn't approved 
yet, it can be changed. However if your parameter is as newly defined as 
I think, it might be easier for you to rename it.

To avoid future problem with this, the 3GPP SDP parameters in the PSS 
specification should be registered. The question here is what level is 
needed for registering the parameters. The previous SDP specification is 
not clear and the new specification requires a specification, which will 
exist when Release 6 is finished. So any advice from the chair on 
appropriate level to register them? Is a registering request pointing to 
26.234 enough or should a draft be written for this? I would also like 
to point out that there are a few more attributes also defined:

- "a=X-predecbufsize:<size of the hypothetical pre-decoder buffer>"
This gives the suggested size of the Annex G hypothetical pre-decoder 
buffer in bytes.

- "a=X-initpredecbufperiod:<initial pre-decoder buffering period>"
This gives the required initial pre-decoder buffering period specified 
according to Annex G. Values are interpreted as clock ticks of a 90-kHz 
clock. That is, the value is incremented by one for each 1/90 000 
seconds. For example, value 180 000 corresponds to a two second initial 
pre-decoder buffering.

- "a=X-initpostdecbufperiod:<initial post-decoder buffering period>"
This gives the required initial post-decoder buffering period specified 
according to Annex G. Values are interpreted as clock ticks of a 90-kHz 
clock.

- "a=X-decbyterate:<peak decoding byte rate>"
This gives the peak decoding byte rate that was used to verify the 
compatibility of the stream with Annex G. Values are given in bytes per 
second.

- "a=framesize:<payload type number> <width>-<height>"
This gives the largest video frame size of H.263 streams.

- "a=3GPP-Adaptation-Support"

Which also should be registered.

Cheers

Magnus

Jonathan Rosenberg wrote:

>> But I also think it is important that IETF takes into account these 
>> sections somehow, since they may have an impact on several proposals, 
>> say such as transport independent bw modifiers?
>>
>> br
>> g
>>
>>
>> No there are no IETF pointers about this proposal. This work is 
>> totally created within the 3GPP SA4. There should probably have been 
>> some review   by the IETF before the acceptance of the proposal, but 
>> that has not happened. However as the Release 6 has not been approved 
>> yet, any bugs in this proposal can still be fixed.
>>
>>> I am looking for ietf pointers (if there are any) on the sdp 
>>> descriptions provided in 
>>> http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_28/Docs/ document 
>>> s4-30680.
>>> This e-mail message (including any attachment) is intended only for 
>>> the personal use of the recipient(s) named above. This message is 
>>> confidential and may be legally privileged. If you are not an 
>>> intended recipient, you may not review, copy or distribute this 
>>> message. If you have received this communication in error, please 
>>> notify us immediately by e-mail and delete the original message. Any 
>>> views or opinions expressed in this message are those of the author 
>>> only. Furthermore, this message including any attachment does not 
>>> create any legally binding rights or obligations whatsoever, which 
>>> may only be created by the exchange of hard copy documents signed by 
>>> a duly authorized representative of Vidiator Technology (US) Inc.
>>> transport changes. This needs to be added to the transport 
>>> negotiation notes.
>>>
>>>> Yes, I would also think that in most cases the application will not 
>>>> know about the change of transport until it actually happens. This 
>>>> will probably result in the loss of some media packets. This loss 
>>>> can be dealt with in a few different way depending on the what the 
>>>> application can use: media level retransmission, RTSP go back 
>>>> through PAUSE and PLAY.
>>>>
>>>> However in regards the question about what your assumption are and 
>>>> why you need Range in the request I think your answer clearly points 
>>>> out that there are no need for Range in the Request. There seem to 
>>>> be reasons for it to be allowed in the Response, to indicate the 
>>>> correct new synchronization after the change of address.
>>>>
>>>> So are you still seeing any need for Range in the SETUP request? If 
>>>> that can be motivated I definitely think there will be possibility 
>>>> to change the specification to allow for this. However this would 
>>>> need further investigation.
>>>>
>>>>
>>>>
>>>>
>>>>> a) How does a mobile client get notified about new transports - 
>>>>> such as  a new IP address?  How far ahead of time does the client get
>>>>>  notified?
>>>>
>>>>
>>>> I would say that this is not a question we can answer. I think we 
>>>> simply need to ensure that the solution works with both sufficient 
>>>> notification and without. However without overlap in transport 
>>>> availability, there will be losses of media packets.
>>>>
>>>>
>>>>
>>>>
>>>> As I have stated prior I think we must require the client to have 
>>>> access to an interface it sends traffic to. If there is overlap I 
>>>> would assume that it can receive data on both during this period. I 
>>>> don't find it reasonable to get any guarantees from the networks. I 
>>>> would assume that any switch of network depends on the change of 
>>>> access technology, for example by switching from cable to WLAN or to 
>>>> 3G mobile network. The probability that there will exist any 
>>>> mobility functionality between these networks seems very small.
>>>>
>>>> I think that we should design our solution to allow the mobility, 
>>>> only note that it may loss some packets
>>>>
>>>> Cheers
>>>>
>>>>
>>>> Magnus Westerlund
>>>>

-- 

Magnus Westerlund

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Nov 2003 12:18:44 -0500

Magnus Westerlund wrote:

> solution and included in the specification.

I had no idea about it.

> However as it isn't approved 

Yes, its no big deal to change. I am worried more about the potential 
for other namespace collisions.

> specification should be registered. 

Ideally, they should be shared before registration too...

> The question here is what level is 
> appropriate level to register them? 

Well, the tact we took with the SIP documents was this. 3gpp-specific 
headers were created through IETF RFCs that created "P-headers" that 
were not for general use. The ensured that the ietf retained ownership 
and change control for sip and its extensions, while giving 3gpp the 
ability to have things they needed. Given that the new sdp spec 
requires an rfc to register parameters, it would seem to imply a 
similar kind of thing - there should be a doc that goes through the 
ietf process that defines these attributes and registers them. The 
3gpp specs could then reference this doc.

I think we ultimately need AD input here on the direction this should 
go. The "alt" collision is a clear indicator that there is a REAL 
problem here.

-Jonathan R.