Andrea Rizzi wrote:
> Just read section 6.1 .
> Should the attribute be missing in the answer, it implicitly means sendrecv,
> i.e. it is forbidden!
Agree it is forbidden now. But in RFC 2543 there was no specification of
this. So receiving none of the direction attributes in the response can
be viewed as an indication that the other party doesn't understand your
sendonly, so your attempt at hold has failed. You might want to fall
back to the old c=0.0.0.0 approach for indicating hold in this case.
More comments inline on Benoit's message that I somehow missed.
Paul
> Andrea
>
> -----Original Message-----
> From: David Benoit [mailto:[EMAIL PROTECTED]
> Sent: mercoledì 27 giugno 2007 16.21
> To: Andrea Rizzi
> Cc: 'varun'; [email protected]
> Subject: Re: [Sip-implementors] Call hold and a = inactive
>
> Option 3 is definitely legal for clients that were written before RFC 3254
> existed as it is the default value (i.e. if B sends A "sendonly" and A
> responds with no state, it defaults to "sendrecv").
>
> Please tell me specifically what part of RFC 3264 you mean when you said
> it is forbidden as I can find no reference to that.
>
> Thanks,
>
> David
>
> On Wed, Jun 27, 2007 at 03:51:41PM +0200, Andrea Rizzi wrote:
>> Option 3 is forbidden by RFC3264!
>>
>> Andrea
>>
>> -----Original Message-----
>> From: David Benoit [mailto:[EMAIL PROTECTED]
>> Sent: mercoled? 27 giugno 2007 15.20
>> To: varun
>> Cc: Andrea Rizzi; [email protected]
>> Subject: Re: [Sip-implementors] Call hold and a = inactive
>>
>> Hi,
>>
>> The exchange of the activation state can be thought of like the following
>> conversation (which may aid in the understanding):
>>
>> User B wants to put A on hold so it sends "sendonly" to A:
>> - Hey A, I'm not going to send you any media for a while,
sendonly doesn't mean that. It means "I'm not going to process media
from you for awhile, so please don't send me any. But I'd like the
option of continuing to send media to you". It doesn't say for sure that
any media will be sent, or what the significance of that media is (music
on hold vs something more useful.)
>> so please
>> don't think that the call is dead because of that. I'll let you know
>> when I'm back.
>>
>> In response to that, A has a number of options.
>>
>> Option 1: User A sends back "recvonly":
>> - Hey B, thanks for telling me that. I won't send you any media until
>> you tell me otherwise, but I will still pay attention to anything you
>> send to me.
>>
>> Option 2: User A sends back "inactive":
>> - Hey B, thanks. It you aren't going to listen, I'm not going to listen
>> either. Let me know when you want to talk again.
>>
>> Option 3: User A sends back "sendrecv":
>> - Hey B, thanks for telling me that, but I don't really care. I'm not
>> going to kill your call because you don't send me any media. I will
>> still send you media and you can just ignore it. You can still send
>> me media and I'll pay attention to it.
As noted above, this isn't permitted by 3264. But a 2543 implementation
wouldn't understand a=sendonly and so would ignore it, and not send any
corresponding a-line in the response. This can be viewed as meaning what
option 3 says.
>> It is not really clear which of the options should be chosen in all
>> cases. And all of these options are valid and legal responses.
>>
>> For option 1, this means that media won't be flowing from A to B, but as
>> soon as B wants to start sending media again, it will be accepted by A
>> even before the "off hold" exchange happens.
Huh?
Agreed it means that media won't be flowing from A to B, but media *may*
be flowing from B to A. It could be MoH, or B may have an open mic while
on hold. (Not such a great idea.)
>> For option 2, no media should flow between A and B or visa versa.
>> However, this means that some clients may not accept any media from the
>> other side until the state changes, meaning the completion of the "off
>> hold" exchange would have to happen before media was accepted.
Yes.
>> This is
>> sometimes problematic if there is more delay in the signaling (either from
>> the path or the processing) than there is for the media. This is a real
>> problem on a lot of networks, so be careful.
Well, normally it takes more that talking to take you off hold. Normally
you need to press a button. So its a matter of there being some response
time to the button press. If you press the button and start talking
simultaneously then you might see some clipping.
>> Option 3 is more like option 1 than 2. As B should really "discard" any
>> media it receives after sending out the "sendonly" (as it has said to A "I
>> don't want your media"), it is actually okay that A keeps sending to B.
>> It only "wastes" bandwidth. However, in some cases the A may be a piece
>> of equipment not capable of setting this particular option (either because
>> it is old, incorrect, etc.).
>>
>> So, this isn't really a prescription for what you should do. If you are a
>> UA (i.e. a client) I would tend toward option 1. It has the least chance
>> of introducing any type of problem where the media from B will get lost
>> when B takes the call off hold.
>>
>> David
>>
>> On Wed, Jun 27, 2007 at 05:46:51AM -0700, varun wrote:
>>> Hi,
>>> I have still not got a complete answer.
>>> Case1: Putting a call on hold by using send only(Party
>>> A) and the other end(Party B) reposning by recvonly ,
>>> this case still has one directional media path
>>> open(From A->B).
>>> What is the case when the other end(Party B) responds
>>> with a = inactive...
>>> does it mean no media path in both directions or same
>>> as case 1( one way media from A->B)/.
>>> Please reply ASAP.
>>>
>>> Thanks
>>> varun
>>> --- Andrea Rizzi <[EMAIL PROTECTED]> wrote:
>>>
>>>> There are no violations at all in responding with
>>>> inactive, and as you
>>>> mentioned this will suspend any media, as the
>>>> holding procedure is
>>>> definitively a new offer/answer exchange.
>>>> Actually, in my opinion, this would be the preferred
>>>> way to implement the
>>>> call hold service, to save bandwidth, of course by
>>>> guessing that the
>>>> terminal responding with inactive is able to play a
>>>> locally-generated hold
>>>> tone. Moreover, I've seen very few holding terminals
>>>> sending content (as a
>>>> hold tone or music) over RTP after a
>>>> sendonly/recvonly exchange.
>>>>
>>>> Andrea
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 7
>>>> Date: Tue, 26 Jun 2007 20:14:01 -0700 (PDT)
>>>> From: varun <[EMAIL PROTECTED]>
>>>> Subject: [Sip-implementors] Call hold and a =
>>>> inactive
>>>> To: [EMAIL PROTECTED]
>>>> Message-ID:
>>>> <[EMAIL PROTECTED]>
>>>> Content-Type: text/plain; charset=iso-8859-1
>>>>
>>>> Hi,
>>>> If user B wants to put user A on Hold, it can send a
>>>> =
>>>> sendonly to A and expects A to return a = recvonly.
>>>> This way there is a one way audio channel open from
>>>> B
>>>> to A.
>>>> What if user A responds with a = inactive..is that
>>>> valid? Does it mean that media streams are on Hold
>>>> in
>>>> both directions?
>>>>
>>>> Thanks
>>>> varun
>>>>
>>>> _______________________________________________
>>>> Sip-implementors mailing list
>>>> [email protected]
>>>>
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>>
>>>
>>>
> ____________________________________________________________________________
>> ________
>>> Looking for a deal? Find great prices on flights and hotels with Yahoo!
>> FareChase.
>>> http://farechase.yahoo.com/
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>> --
>> [EMAIL PROTECTED] | Principal Software Engineer | +1-902-832-2649
>> "Complex problems have simple, neat and wrong solutions" - H. L. Menken
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
