varun wrote:
> Hi,
> How does sending a = sendonly put the other guy on
> hold( and the other end responding with a = recv
> only).
I think this is a legacy of Music on Hold. Namely, you may still want to
play music to the guy you have held, but you don't want to hear anything
back from him.
It is the recommended way to "put on hold", but it is neither the only
thing one might do, nor is it the only situation in which this mechanism
is used. So a recipient does not know that it has been "put on hold"
when it receives this. All it knows is that it should not transmit.
> What if its a invite and not a re-invite. In case of
> invite, it would mean a one way audio channel and in
> case of re-invite would mean a call hold.Is tha right?
No.
In the invite case, it could mean that it has been invited by someone
that wants to start the call on hold. In the reinvite case it might mean
that there is a desire to switch to one way media that is unrelated to
call hold.
There is no way to know these things by examining the signaling. It is
all a matter of *intent* which is not signaled.
> Also, if two end supports different codecs ( no common
> codec) is there a way to still establish a call
> between two ends?
Depends on what you mean, and what you want.
It is valid for the callee to answer with port=0, rejecting the media
because there are no codecs in common, but accepting the call without
any working media. Then you have "established the call" but cannot
exchange media. Its probably not useful, unless its followed with some
other action, such as another offer. Note that afaik this is not a
common way to proceed.
If you are asking how to get a transcoder involved, sure there are a
number of ways to do that. One way is for the UAS to act as a 3PCC
controller and invite a transcoder. But there are lots of ways.
Paul
> Please let me know.
>
> Thanks
> Naven
>
> --- Paul Kyzivat <[EMAIL PROTECTED]> wrote:
>
>>
>> gaurav wrote:
>>> Hi All,
>>>
>>> I have following doubts regaridng the Call Hold
>> implementation in SIP/SDP:
>>
>> First, you must understand that SIP doesn't actually
>> have a way to
>> signal Call Hold. What it has is a way to signal
>> changes in the handling
>> of media that may be useful to a UAC implementing a
>> call hold feature.
>> The difference is that the signaling thats useful
>> for call hold is also
>> useful for other things as well. The UAS has no way
>> to be certain that
>> the UAC is specifying the start of a hold, or
>> something else that uses
>> the same mechanisms.
>>
>>> 1.. What is the behavior of UAC and UAS in case
>> the Call Hold using Re-Invite.
>>
>> The usual approach is to send an offer with
>> a=sendonly, to which the
>> answer is normally a=recvonly. Another possibility
>> is to offer
>> a=inactive, to which the response should also be
>> a=inactive.
>>
>> An older approach is to offer c=0.0.0.0.
>>
>>> 2.. How can UAS reject the Call Hold request, as
>> the control of the call hold is with the UAC.
>>
>> You can't reject call hold because it isn't
>> signaled. (See above.)
>>
>> I don't believe there is a valid way to reject
>> a=sendonly or a=recvonly
>> either. If you understand them, then to be compliant
>> you must respond in
>> a compatible way.
>>
>> You could pretend not to understand, and just not
>> return a matching a=
>> line for the a=sendonly. But I don't recommend that.
>>
>> I don't understand why you want to do this. If the
>> other side doesn't
>> want you to send it stuff, you can' force it to do
>> so. At best you might
>> still be able to send media, but the other end will
>> be ignoring it. If
>> the user on the other side has pushed the HOLD
>> button on the phone, what
>> do you want to happen? Do you want the button to pop
>> back up?
>>
>>> 3.. If UAS rejects with 488 Not Acceptable Here,
>> then what should be the ideal behavior of UAC, if it
>> still want the call to be put on Hold.
>>
>> If you are lucky, it will try to cope. It could try
>> an alternative
>> mechanism, such as offering c=0.0.0.0, or it might
>> just send your media
>> to the bit bucket. But it also may decide that you
>> are a problem and
>> just send you a BYE.
>>
>>> 4.. Can a reuqest to put the call on hold be
>> rejected by UAS, if yes, then what is the call Flow.
>>> We are testing the Call Hold Flow through eBean
>> Soft Phone and we are rejecting the request to put
>> the call on hold by 488 to re-invite request, but
>> the eBean Soft phone is not releasing the call hold
>> when it receives the 488 response to re-invite.
>>> Where could be the problem? Please help in
>> understanding the porblem and arriving at a
>> solution.
>>
>> Stop trying to prevent the other end from doing what
>> it wants to do.
>>
>> Paul
>>
>>> regards
>>> Gaurav
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
