Jonathan Rosenberg dynamicsoft IETF 52 History RFC2543 had - PowerPoint PPT Presentation

draft-rosenberg-mmusic-sdp-offer-answer-00.txt Jonathan Rosenberg dynamicsoft IETF 52

History • RFC2543 had appendix B, which specified SDP usage • As bis evolved, this section become more independent and moved towards a well-defined offer/answer model • Agreement at IETF 51 in both mmusic and sip to extract to separate doc and progress in mmusic • NB: sip-bis depends on this draft!! Thus, this draft is needed for 3gpp R5

Open Issues • Allow changes in the media type (audio/video) of a • Offerer prepared to stream? receive media when it – Example usage is sends offer, even in voice->fax bidirectional streams – Only really reasonable – Flemming argues it if SIP issue #24 allows should be prepared to for replacing streams both send and receive • If you change audio to message, its same as a – Seems academic point new stream in the old to me slot • Proposal is to allow – I say yes

Multiple streams of same type • What is meaning when there are multiple streams of the same type? – Spec says to send a copy of your media on each, and mix media received on each – Clearly specific to audio, doesn’t make sense for • Video or IM • Cases where there are multiple media sources/sinks

Proposal • Model is – Element has sources (green) and sinks (blue) for each type SDP – Streams are uni or bi-directional • Requirement – Media received on a stream MUST get sent to one or more sinks – Sources MUST go to one or more stream – When more than one source transmits on a stream, it must be “combined” in some implementation specific way f 2 f 1 – When more than one stream source transmits to a sink, it must be “combined” in some implementation sink specific way – Mapping of sources/sinks to streams f 1 and f 2 are surjections beyond the above rules is local policy

Synchronizing Codec Changes • A and B are in a • If there is overlap session X, Y codecs – Proposal I: when a non-overlapping codec • A offers B new SDP is received, OR 1 with new codecs Y,Z minute passes – B answers with Y,Z • Timer based stuff ugly • Issue: when can A and – Proposal II: answerer B cease being includes SN of first packet sent after prepared to use X? answer was sent – If there is no overlap – • Offerer can stop when it its easy – when media receives that packet from new codec arrives • Only works for answerer

Unidirectional codecs in a bidirectional stream • Motivation • Current text – PC phone calls media – Offerer omits rfc2833 server entirely – PC phone can send DTMF, – Answerer adds rfc2833 can’t receive – Semantic: codecs not – MS can receive DTMF, not send in offer, added to – Would like PC to use some answer, on a sendrecv codec when sending voice, stream, are recv only switch to rfc2833 for – Problem: makes DTMF interpretation context • Question dependent – How to represent? • Breaks 3pcc

Other proposals • Rfc2833 in NEITHER • Offerer includes offer or answer rfc2833 anyway, even – MS adds an extra m though it can’t receive line through a new it offer • Answerer can’t insert – Extra m line is recvonly with rfc2833 it unless it can BOTH – Use FID to group them send and receive it – Complex – My preference • Others?