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.
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.
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.
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 think there is a fruitful area for investigation here.
Thanks,
Paul
On 7/7/11 5:55 AM, Saúl Ibarra Corretgé wrote:
>
> On Jul 7, 2011, at 11:48 AM, Iñaki Baz Castillo wrote:
>
>> 2011/7/7 Saúl Ibarra Corretgé<[email protected]>:
>>> When doing a call transfer, the party sending the REFER communicates the
>>> URI the recipient is supposed to call by using the Refer-To header. This
>>> header may also contain Replaces, in order to indicate that a dialog should
>>> be "replaced". Is there a standard mechanism to communicate *what* streams
>>> should the recipient use when sending the outbound INVITE?
>>
>> I assume you mean "which *kind* of streas", right? this is: audio,
>> video, MSRP...
>>
>
> Yes, wrong wording.
>
>>
>>> This would let the REFER recipient know if he should offer audio, video,
>>> MSRP chat or any other kind of stream. Is there any RFC/draft defining this?
>>
>> I assume that in case I've established a dialog with you and
>> negotiated audio and msrp, then in case you send me a REFER I would
>> generate my new INVITE with offering the same kind of streams. I see
>> the utility of what you mean however.
>>
>
> Indeed, this is the use case that came to my mind.
>
>> PS: I don't know such spec (if it exists).
>>
>
> I hope it does, I don't like the idea of implementing custom behavior :-S
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
