??? wrote:
> Dear Paul:
>
> Thanks for you explanation. And I want to know more specifically on this
> topic.
>
> In your summarizing, it says "an offer always contains what the offerer
> *wants*", but what if the offer's "wants" is ambiguous?
I guess it must do as good as it can to get it right.
> B receives
> "sendonly" and responses "recvonly" passively, and B doesn't indicate
> further behavior (hold or resume).
If the call was initially sendrecv, then B was presumably willing to
both send and receive. (Otherwise B wouldn't have responded that way
initially.)
When B receives "sendonly" from A, it understands what A wants, and
responds with "recvonly" to comply with A's wishes. Under normal
circumstances that doesn't change what B wants, only what B is currently
doing. B most likely still wants to be sending and receiving. So when
given an opportunity to say what it wants, that is what it should say.
> In fact, B wants nothing, B is just
> held there. If B needs to play the role of offerer in 200 OK response
> followed re-invite from A with empty sdp, should B treat that as a new
> SDP negotiation and return the full capabilities?
We reach the same conclusion but with a different rationale.
Consider another case that is more extreme than the one I provided earlier:
- A and B have a dialog
- A reinvites with offer of *inactive* to establish hold
(it doesn't do music on hold)
- B answers with inactive to acknowledge the hold
(but it still *wants* to send and receive)
- later, B also decides to hold the call. It also doesn't
do music on hold and so doesn't want to send or receive.
Since the stream is already inactive, it does no signaling
to indicate its new state
- For some reason, A later sends an offerless reinvite to B.
B is still in hold state and doesn't want to send or receive.
So it offers inactive. Regardless of what A wants at this
time the answer must be inactive.
- later, A decides to go off hold. It now wants to send and
receive, so it sends a new offer with sendrecv.
- B is still in its hold state, not wanting to send or receive,
so it answers with inactive.
- Later B wants to go off hold. So it sends a reinvite with
an offer of sendrecv.
- A also wants to be off hold, so it answers with sendrecv.
The key in the above is that when B first does its own hold there is no
signaling at all. The only change is in what B *wants*.
For devices that are operated by a person, what the device "wants" is
typically determined by the user operating the device, through some
interaction with the user interface of the device, changing its state.
For devices not operated by a person, some way of determining what it
wants must be established. For instance, a B2BUA may have no preference
of its own. If a B2BUA connected to A and B needs to make an offer to A,
it will most likely delegate the decision about what to offer to B. So
then it only matters what B wants.
In the case of a gateway, delegation may be used, as with the B2BUA, or
the gateway may attempt to track the state of the device on the other
side of the gateway so it can determine "want" on its own. Whether this
is possible depends on the protocol on the other side of the gateway.
When no other information is available, "want" should be equated to
"ability". Namely, if media can be received then assume a desire to
receive. And if media can be sent, then assume a desire to send.
Paul
> BR, thanks very much.
> Johnny
>
>
> Summarizing:
> - an offer always contains what the offerer *wants*.
> - an answer is computed as follows:
> . select the answers that are consistent with the offer
> . choose the one of those that is closest to what the
> answerer *wants"
>
> We intend to write something about this in the offeranswer draft, but
> haven't yet.
>
> Paul
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
