AFIK, SIP doesn't provide any mechanism to indicate whether call-progress progress tones are available in-band or need to be generated locally - a SIP end-point can determine by listening to the media stream when it receives the corresponding SIP message or developing a common local policy.
Muthu On Mon, 7 Feb 2005 09:56:59 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Gurus, > > If party-A in a call wants to put the other party(B) on hold, it should > reinvite that party with a sendonly media stream offer. Party-B answers > with a recvonly media stream - the media is now one-way from A to B. > Typically, according to RFC3264 section 8.4, party-A should locally mute. > > However, the question arises when dealing with e.g. music on hold and > call-progress tones. In the situation described above, party-B would be > responsible for generating a call-progress tone locally. But if party-A > would not mute, but instead send media (music on hold or whatever) party-B > should not generate call-progress tones. > > Is there a general way for party-B to decide to either generate > call-progress-tones or to play the media? > > Thanks, > > Martin. > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
