"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-09.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
