Inline
On 7/7/11 11:10 AM, Saúl Ibarra Corretgé wrote:
> Hi,
>
> On Jul 7, 2011, at 3:19 PM, Paul Kyzivat wrote:
>
>> AFAIK there is nothing written specifically about this subject.
>> Some thoughts:
>>
>> - when in doubt, the "obvious" thing to do is to offer whatever
>> you would have if you received an invite without offer.
>>
>> - "more is better" - offering as much as you willing and
>> capable of handling will give the recipient the maximal options
>> to select what it wants.
>>
>> - this may be tempered in cases where it is costly to you to
>> offer something. I guess this would be determined by policy.
>>
>> - in a "Replaces" case, if the replaced dialog is using media
>> that you would otherwise not offer by policy, you may want to
>> override the policy and offer them.
>>
>> None of the above requires the REFER to carry anything new.
>>
>
> Agreed. By "policy" do you mean local policy, right?
Yes.
>> The cases where there may be some value in the REFER carrying some "hints":
>>
>> - you want the referred dialog to offer *less* than it normally would.
>> (This could happen in the splices context, where you might want a
>> device to offer video and not audio.)
>>
>> - you want the offer to include media that its policy would normally
>> exclude. (E.g. video was not already in use, and the device normally
>> doesn't offer video by policy unless the local user of the device
>> does something overt to enable video.)
>>
>> I don't think those cases are compelling, so I'm in no rush to work on a
>> mechanism to deal with them.
>>
>
> I don't think video is a good example, because in most cases it goes together
> with audio, more below.
>
>> Even in normal calling ISTM there is an unexplored area about how to
>> negotiate which media types are used, and how that interacts with user
>> experience. We have been living the simple life where there is generally
>> only one media type (voice) and hence no decisions to be made. But that
>> is now coming to an end.
>>
>
> Indeed!
>
>> Specifically, do video-capable devices offer video whenever they make an
>> initial offer? Or should they wait for the user to manually enable
>> video? If they wait, how would the user know that video is even an
>> option on the call? (There may be a reluctance to establish video by
>> default because the user wants control of when/if his image is seen. And
>> on multifunction devices that share a screen among apps and UI, there
>> may be a reluctance to take screen real estate until its known it is
>> desired.)
>>
>> One solution to that is to offer video, but in recvonly mode initially.
>> Or offer sendrecv but with intent to send video that doesn't originate
>> from the device's camera. (In effect, start with video "muted".) And
>> don't open a window to display video until some is actually received.
>> Instead, have some UI indicators that show the availability of video.
>>
>
> I've seen this implemented as you described in many clients: video is always
> offered but the stream is either recvonly or inactive and is then toggled. I
> guess this will save you some bytes in the SDP in case you don't add the
> stream in the beginning and need to add/remove/add the stream multiple times
> later.
>
> Consider the following case, the one that made me write the email in the
> first place: I (Bob) am having a MSRP chat session with Alice. Then Carol
> calls me with audio. I can do both things at the same time, and I may want to
> transfer Alice to Carol, but I'd like to suggest Alice that she uses audio in
> the INVITE she sends to Carol.
>
>> I think there is a fruitful area for investigation here.
>>
>
> I'd be willing to collaborate if there is interest on the subject :-)
I see Dale replied as well, with something a little like my comment, but
different emphasis.
Lets see if there is more interest here.
I might have a bit of time to work on this after the upcoming ietf
meeting is over. Till then I can continue to discuss via email but can't
spend much more time than that on it.
I expect this is an area where there should be room for various kinds of
policy control as a part of UA innovations, but where the basic
offer/answer approaches may need standardization to ensure that
interoperation brings reasonable results.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
