Hi:
From RFC 3264:
8.4 Putting a Unicast Media Stream on Hold
If a party in a call wants to put the other party "on hold", i.e.,
request that it temporarily stops sending one or more unicast media
streams, a party offers the other an updated SDP.
If the stream to be placed on hold was previously a sendrecv media
stream, it is placed on hold by marking it as sendonly. If the
stream to be placed on hold was previously a recvonly media stream,
it is placed on hold by marking it inactive.
This means that a stream is placed "on hold" separately in each
direction. Each stream is placed "on hold" independently. The
recipient of an offer for a stream on-hold SHOULD NOT automatically
return an answer with the corresponding stream on hold. An SDP with
all streams "on hold" is referred to as held SDP.
Certain third party call control scenarios do not work when an
answerer responds to held SDP with held SDP.
How does this behavior differ from section 6, initial exchange?
I have seen an softphone that does no seem to understand the media
direction attribute. Is it even possible for a device that does
understand and use media direction to interoperate correctly with one
that does not?
-Rick
Rick whitesel
Technical Leader
Contact Center Solutions
[EMAIL PROTECTED]
Phone :978-936-0479
Fax :978-936-2204
1414 Massachusetts Avenue
Boxborough, MA 01719
www.cisco.com <http://www.cisco.com/>
Simplify, Standardize and Conserve
"When a country is well governed, poverty and a mean condition are
things to be ashamed of. When a country is ill governed, riches and
honors are things to be ashamed of." -- Confucius --
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
