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

From: "Gamze Seckin" <[email-masked]>
Date: Thu, 6 Nov 2003 13:41:37 -0800

Hi Jonathan

The "alt" in the ice draft is different than the "alt" in the 3gpp document.

The purpose of the alt, alt-default-id and alt-group definitions in 26.234 for Rel6 is to define alternate groupings for several streaming tracks, based on bitrate or language. 
And it is an efficient method. I believe it should be taken into account by IETF for further work on sdp related efforts. 

However I am not sure how to solve the naming overlap.

g

Gamze Seckin, Ph.D.
Vidiator Technology US
www.vidiator.com

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

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.

Gamze Seckin wrote:

> 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
> 
> 

-- 
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

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