> -----Original Message----- > From: Worley, Dale (BL60:9D30) > Sent: Wednesday, September 03, 2008 4:37 PM > To: Joly, Robert (CAR:9D30) > Cc: M. Ranganathan; [EMAIL PROTECTED] > Subject: RE: [sipX-dev] Call pickup SDP negotiation question. > > On Tue, 2008-09-02 at 16:19 -0400, Joly, Robert (CAR:9D30) wrote: > > I'm not convinced that the media relay would need to rewrite the > > payload type field of the RTP packets. The payload type an > endpoint > > puts in the SDP is the payload type the endpoint expects to receive > > and *would* prefer to send. My understanding of SDP and the > > offer/answer model is that it allows for asymmetric payload types > > where each endpoint is obligated to use the payload type > requested by > > the far-end when sending media packets relieving the media > relay from > > having to do any translation. > > sipXbridge will generate an answer to the INVITE/Replaces, > and that can force 206 to send using the payload numbers > expected by the ITSP (which the ITSP previously supplied). > > But without doing a re-INVITE to the ITSP, there's no way > that sipXbridge can change the (already established!) payload > numbers that the ITSP is using to send RTP so that they match > what 206 has declared that it is using to listen. >
The point I was trying to make is that there is no requirement for the payload types to match - media exchanges with asymmetric payload types are legal. So, for example, it is possible for 206 to send G.711 mu-law using PT 96 and the ITPS to send g.711 mu-law using PT 0. All that is mandated is that an endpoint uses the PT that the far-end requested in its SDP when transmitting media packet to it. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
