Sarju Garg wrote:
> Hi all,
>
> I think the basic query is
>
> a) that in case UAS does not support call hold feature, what handling in
> mentioneed in SIP RFC. We have gone thru RFC 3261/3264 but to our
> understanding, it does not specify this. Is there is a suggested
> handling? Can UAS reject this message or ignore it, or ignore/reject and
> clear the call?
From the perspective of the UAS it isn't a matter of supporting call
hold, since it doesn't ever know that is what is happening.
This is a matter of whether the UAS supports SDP according to RFC 2327
or RFC 4566, and whether it supports offer/answer according to RFC 2543
or RFC 3261. In particular, its a matter of whether the UAS supports
offer/answer using a=sendrecv/sendonly/recvonly/inactive, or only
a=sendrecv/sendonly/recvonly and whether it supports use of c=0.0.0.0.
Note that while RFC 4566 is relatively new, versions of it covering this
have been around for a *long* time and are widely implemented.
Even RFC 2327 had a=sendrecv/sendonly/recvonly. But IIRC RFC 2543 didn't
specify offer/answer procedures for using this. So the worst case is
that an offer contains one of these attributes, and the answer doesn't.
This indicates that the UAS didn't understand, and so is still expecting
a sendrecv stream. The UAC can cope with this as it wishes. For instance
it can discard incoming media and send none. Or it can do another
reinvite using the 2543 technique with c=0.0.0.0.
> b) Also, in case UAC sends a call hold request, what handling is
> prescribed for UAC? Should it wait till 200 Ok before putting call on hold.
This is a local issue. Regardless of the signaling, it is free to change
the audio source, or mute it, and discard incoming audio.
Paul
> Regards
> Sarju
> # 9810304396
> ----- Original Message ----- From: "Agrawal, Vishal"
> <[EMAIL PROTECTED]>
> To: "Paul Kyzivat" <[EMAIL PROTECTED]>
> Cc: "Blasko, John" <[EMAIL PROTECTED]>;
> <[email protected]>
> Sent: Friday, October 20, 2006 8:39 PM
> Subject: Re: [Sip-implementors] Query: Call Hold Implementation in SIP/SDP
>
>
>> 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?
>>
>> 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.
>>
>> 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? 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?
>>
>> -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: [email protected]; 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
>> [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
>>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
