> > There are a number of approaches, depending on what you want > to accomplish. > > sipXbridge could send an INVITE/Replaces to the outside > caller, and put 206's offer in the INVITE/Replaces. This > forces the outside caller to provide an answer that fits > within the offer/answer sequence between 206 and sipXbridge. > But we don't depend on ITSPs implementing INVITE/Replaces, > and in any case, the outside caller could reject it. > > If you can't replace the outside dialog, then you have to > beware the rules on re-using m-line slots and codec numbers > within an offer/answer series. Since sipXbridge didn't start > *either* offer/answer series, I don't see any way for it to > force there to be a common codec number between the two > dialogs, unless it's willing to send re-INVITEs to > *both* sides in order to declare one, new codec number within > both dialogs. (Since both dialogs may have put exactly the > same set of codec numbers in their offers, but with different > codecs.) But we can't depend on ITSPs supporting re-INVITE, > UPDATE, or INVITE/Replaces. > > I think that your best bet is to choose the common codecs > between the two offers, but have your media relay be prepared > to rewrite the codec numbers in the RTP packets. That works, > as long as there *is* a common codec between the two offers.
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. > And if there isn't, you can make the INVITE/Replaces from 206 > fail in the appropriate way. > > Dale > > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
