Paul/Kaiduan,
It was pretty insightful. So, applying Paul's logic, is the following a
valid scenario?
A,B are video endpoints and in a call with 2-way audio video flowing.
Videocalls support the concept of presentation, wherein only one
participant is allowed to generate videocontent for all to view. Since
this kind of call can graduate to a conference also, we need token
control so that one participant can grab the floor from another. Anybody
can voluntarily release a floor, etc. Whoever has the token has the
right to generate videocontent)
Now,
(A grabs the token by the relevant procedure and all endpoints are aware
that A has the token.
Now A sends the offer to start generating videocontent)
A---------------->B
(SENDONLY)
A<----------------B
(RECVONLY)
(After a while, B grabs the token by the same procedure and A
relinquishes the token.
Now, since B wishes to start generating video, is this valid?)
A<----------------B
(SENDONLY)
A----------------->B
(RECVONLY)
Here, we have bypassed the "inactive" state that you guys discussed.
Here A knows that it no longer has the token and is OK with responding
with "recvonly". This is not a two-way hold.
I dont think anything is violated here. Only thing is that there is a
parallel protocol that conveys information to the endpoints in addition
to the offer/answer.
-Thanks
R.Kamath
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
kaiduan xie
Sent: Thursday, December 04, 2008 3:33 AM
To: Paul Kyzivat
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] two-way hold/resume
"Each time you are considering what to put into the SDP, ask yourself
"*why* am I making this choice of the direction?"
The possible answers are:
- this is what I want/need based on *my* local state
- this is not what I want, but it is the closest to
what I want that is permitted in an answer given what
I just received in the offer.
- this is what I think I ought to offer based on my
*inference* about what the other guy wants.
If
you give the third answer, then you are asking for trouble. The fact is
that you cannot know what the other guy wants. Some day you will get it
wrong, and end up in a less desirable state that you would have if you
had not guessed. And when *both* sides start guessing about what the
other wants, you start to see "stuck on hold" scenarios.
There is no reason to *offer* less than what you want. The answer will
take care of what the other guy wants."
This is very insightful. Thanks a lot for the detailed explanation.
kaiduan
----- Original Message ----
From: Paul Kyzivat <[EMAIL PROTECTED]>
To: kaiduan xie <[EMAIL PROTECTED]>
Cc: sip-implementors@lists.cs.columbia.edu
Sent: Wednesday, December 3, 2008 3:31:45 PM
Subject: Re: [Sip-implementors] two-way hold/resume
inline.
kaiduan xie wrote:
> Hi, all,
>
> Consider the following case, what are the right values in SDP in
INVITE/200?
>
> A B
> | INVITE/SDP1 |
> |-------------------------->|
> | 200/SDP2 |
> |<--------------------------|
> | ACK |
> |-------------------------->|
> ........................ Call is up
>
> A initiates hold
>
> | SDP3/sendonly |
> |-------------------------->|
> | SDP4/recvonly |
> |<--------------------------|
>
> B initiates hold
> | SDP5/? |
> |<--------------------------| | SDP6/? |
> |-------------------------->|
>
>
> A resumes
> | SDP7/? |
> |-------------------------->|
> | SDP8/? |
> |<--------------------------|
>
> B resumes
> | SDP9/? |
> |<--------------------------|
> | SDP10/? |
> |-------------------------->|
>
> Here, the direction attribute value is of interest. From
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-0
9.txt, my understanding is:
>
> SDP5: sendonly
> SDP6: inactive
Yes, that would be my recommendation if B would otherwise desire
sendonly (because it wants to play MoH).
> SDP7: sendrecv
> SDP8: sendonly
Yup.
> SDP9: sendrecv
> SDP10: sendrecv
Yup.
> Is my understanding correct? Can we do as below?
>
> SDP5: inactive
> SDP6: inactive
Certainly you MAY. It is probably the best choice if B isn't interested
in sending anything while it has the call on hold.
> SDP7: recvonly
Does A not *want* to send? By offering recvonly, it is making an
assumption about B that it ought not make. Things might work out ok, but
this is asking for trouble.
> SDP8: sendonly
While B is permitted to do this, it isn't consistent with what it did in
SDP5. There it indicated it wasn't interested in sending anything. So in
this case, I would expect that it again wouldn't be interested in
sending anything, and so would respond with inactive.
> SDP9: sendrecv
> SDP10: sendrecv
>
> Thanks for the input.
Each time you are considering what to put into the SDP, ask yourself
"*why* am I making this choice of the direction?"
The possible answers are:
- this is what I want/need based on *my* local state
- this is not what I want, but it is the closest to
what I want that is permitted in an answer given what
I just received in the offer.
- this is what I think I ought to offer based on my
*inference* about what the other guy wants.
If you give the third answer, then you are asking for trouble. The fact
is that you cannot know what the other guy wants. Some day you will get
it wrong, and end up in a less desirable state that you would have if
you had not guessed. And when *both* sides start guessing about what the
other wants, you start to see "stuck on hold" scenarios.
There is no reason to *offer* less than what you want. The answer will
take care of what the other guy wants.
Does that make sense? That is what I have tried to make clear in the
offeranswer draft.
Thanks,
Paul
__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
