Subject: Re: SDP media alignment in SIP

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 20 Apr 1999 09:21:51 -0500

If the application is implemented in this manner, how will it handle a media
stream that changes codecs?

Wouldn't it be simpler for the application to simply pass the media socket
to a "RTP playback" library, and let that library handle all the mess of
decoding, demultiplexing, playing, etc?

Stephen

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        NSA, Network Consulting Engineer
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Pager: 800-365-4578 / 800-901-6078
C I S C O S Y S T E M S   Email: [email-masked]

-----Original Message-----
From: Anders Kristensen <[email-masked]>
To: confctrl <[email-masked]>
Date: Tuesday, April 20, 1999 4:54
Subject: Re: SDP media alignment in SIP

>It doesn't seem very outlandish to imagine an application using multiple
>"media handling" applications or software libraries for handling
>different codecs, with each of these apps/libs using separate port
>numbers. The last thing you'd want to do is to demultiplex RTP streams
>at an application level when all actual media handling takes place
>elsewhere.
>
>--
>Anders Kristensen <[email-masked]>,
>http://www-uk.hpl.hp.com/people/ak/
>Hewlett-Packard Labs, Bristol, UK

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 20 Apr 1999 15:37:08 +0100

> decoding, demultiplexing, playing, etc?

Yes, that sure sounds simpler but some apps might want to use multiple
such libraries for who knows what reason. Maybe exactly because they
support different sets of codecs.  Anyway, this is getting in to
speculation about how user agents are best structured and that's really
besides the point.

---

From: eubpepe <[email-masked]>
Date: Tue, 20 Apr 1999 19:14:07 +0200

> stream that changes codecs?

I do not see any problems with this as long as the other party
understand that certain codecs have to be sent to other ports. In that
case, there's already a listener on that port that immediately receives
the new stream and directly decodes it. However, if the other party's
audio-module isn't clever enough to send different coded streams to
different ports, there will be a problem.

> decoding, demultiplexing, playing, etc?

That should be all right as long as you have control over all the
multimedia modules yourself (meaning have written them yourself or
require that they is implemented using exactly this method). In general,
however, I expect that one wants to be able to plug in third party
multimedia components into the SIP-UA and in that case one cannot easily
dictate how to do this without putting severe restrictions on
implementations?

> Stephen

The reason why I defend this usage is that in Ellemtel's SIP-UA we
actually already have a multimedia plug-in architecture, meaning that as
soon as someone would add a third party audio-module in parallell to the
already existing audio-module we would have to above situation.

Peter Peldan, PhD
Ellemtel Utvecklings AB
[email-masked]