Subject: Re: [MMUSIC] SIP-RSTP Draft

From: lazzaro <[email-masked]>
Date: Thu, 16 Mar 2006 12:36:17 -0800

On Mar 16, 2006, at 9:00 AM, Magnus wrote:
> Scenario 1 - Converged service:
> My main comment on this use case is that I fail to see the need for  
> integrating SIP and RTSP at all. If you are in an RTSP session and  
> there is a incoming multi-media telephony call. Then there is no  
> reason to use RTSP to receive that call. Simply have the TV-box  
> pause the media streaming, or for live resources pipe it to a hard  
> drive while the SIP part of the application negotiate the call and  
> one uses the media encoders and decoders to handle the call. The  
> main point here is that even if one is registered to accept SIP  
> calls on ones TV there is two different context in play, one of the  
> streaming and one for the call. All necessary integration happens  
> within the application within the TV-box. I would also like to  
> understand how the network can make decision on behalf of the end- 
> point application. Please clarify that line of thought.

I might be misunderstanding, but ...

I think there's an implied requirement to let people
take their phone calls without the TV signal stopping.
In this case, the TV volume needs to be dimmed
(for, say, a sports or music video show) or muted
(for, say, a newscast, although some teenagers seem
to be able to track two conversations in parallel :-).

If users want to take calls in speaker-phone mode
and keep the TV volume dimmed, while having the
in-room speaker-phone audio performance be as good
as it could be, one could imagine it helping to have
RTSP/SIP integration ... or on the other hand, one
could also imagine it can all be handed without the SIP
and RTSP modules knowing each other exist, via
an audio mixing module that takes audio in from the
SIP and RTSP modules and has an API for speaker
phone functionality.  Maybe folks who do embedded
system architecture for these devices could speak
up on the issue ...

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---

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

---

From: Dave Singer <[email-masked]>
Date: Thu, 16 Mar 2006 16:14:41 -0800

It may be that there are some odd use cases when (say) a SIP phone 
call is then broadcast ("and on the phone with us we have Colin from 
the IETF...") or when a piece of broadcast content would be relayed 
over a phone call ("hey, Magnus, listen to this internet content I 
found") but in both cases there are lots of other issues that arise 
outside the question of matching the signalling protocol.

If SIP were dramatically simpler than RTSP, or avoided some of the 
problems (e.g. firewall/NAT traversal with RTP, which they both use) 
it might be attractive.

I fully support the idea of doing a feature comparison, if only 
because it may throw up 'holes' in one or other of the two protocols. 
But in general I have to say that RTSP seems to work quite well for 
streaming and the streaming community (ISMA, 3GPP and so on) and I'm 
not sure I am ready to see it 'replaced' without stronger motivation 
and use cases.

Interesting to think about, too.

p.s. I fixed the email thread title to spell RTSP as RTSP not RSTP. 
I hadn't noticed it before because of the title, sorry...
-- 
David Singer
Apple Computer/QuickTime