Agrawal, Vishal wrote:
> Hello Paul,
>
> Why does SIP not recommend a single way to put the UAS on hold? Has
> there ever been any discussion to provide the hold indication in a
> separate SIP header in the re-INVITE?
In general IETF doesn't define services, which is what HOLD is. SIP
defines mechanisms that can be used to realize services.
Also, the harder you look at HOLD the more elusive the concept gets. I
think it would be hard to get agreement on a single definition of HOLD.
> So far I've not seen two SIP endpoints (different vendors) which offer
> or accept the hold and MOH the same way (some expect c=0.0.0.0 (old
> way), some respond back with (a=recvonly in response to re-INVITE with
> a=sendonly), some respond back with (a=sendrecv), some respond back with
> (a=inactive), some can't handle the second re-INVITE with (a=sendonly,
> c=MOH server) to connect them to the MOH server.
There is no reason why they must all use the same way, as long as they
interoperate. The use of c=0 vs the use of sendonly/inactive/etc. it an
unfortunate consequence of evolution of the mechanisms. The use of c=0
was deprecated because it has a number of negative consequences, but it
is hard to get rid of all the old uses.
> Also, the hold is not bidirectional right? If A puts B on hold, A sends
> a=sendonly in re-INVITE and B should send a=sendrecv in the response,
> right?
Wrong. O/A requires that if you are offered sendonly then the only
answers you may give are recvonly or inactive.
My philosophy is that each side watches out for its own interests, and
tries to get as much of that as it can while honoring the O/A rules. So
if A offers sendonly, and B doesn't want to be on hold, the B would like
sendrecv but answers recvonly because that is the most it is allowed to
answer.
If B is then on hold that way, and also wants to put A on hold, it would
offer sendonly. Then A, who wants sendonly, has to answer INACTIVE
because that is all that is consistent with both what it and B want.
> If true, then B can send a re-INVITE to A with a=sendonly, what
> should the response from A now? How should they take the call off-hold?
As long as each side takes care of its own desires, and follows the
rules, it works fine.
Continue the above example. A wants to go off hold. So it offers
sendrecv. But B still wants A to be on hold, so B answers sendonly.
Later, B decides to take A off hold, so it offers sendrecv. A also
doesn't want any hold, so it answers sendrecv, and they can talk.
This works with any sequence of transitions.
It also works if one of the parties chooses to use INACTIVE when placing
the other party on hold. (Because it doesn't intend to use MoH or
otherwise transmit media.)
Note that none of this requires either side to know that the reason for
the other side's actions have anything to do with HOLD. HOLD is only a
local feature that affects the local device's desires regarding use of
media.
Paul
> -Vishal
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul
> Kyzivat
> Sent: Tuesday, October 17, 2006 8:09 AM
> To: Retesh
> Cc: sip-implementors@cs.columbia.edu; gaurav
> Subject: Re: [Sip-implementors] Query: Call Hold Implementation in
> SIP/SDP
>
> Just to restate the point that I an others are trying to make:
>
> THE ANSWERER CANNOT TELL WHETHER THE OFFERER INTENDED HOLD OR ONE WAY
> MEDIA.
>
> You must construct your device so that it doesn't care. If you attempt
> to distinguish the two you will no doubt encounter interoperability
> problems.
>
> Paul
>
> Retesh wrote:
>> Hi Varun
>> If I get your point, you are trying to differentiate call on hold with
>> one way audio.
>>
>> Music on hold implemented is using one way audio (sendonly(in offer)
>> and recvonly(in answer)).
>>
>> Practically, hold (without music) is done by exchanging sdp with
>> attribute as inactive. Also, in case it is done with a=sendonly(in
>> offer) and a=recvonly(in answer), the UAC may chose not to send any
>> RTP data at all.
>>
>> Also INVITE (sendonly) and reINVITE (sendonly) can be treated as 1 way
>> audio and call hold respectively.
>>
>> Hope this helps.
>>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
