On Tue, 2008-09-02 at 12:56 -0400, M. Ranganathan wrote: > Consider an inbound call starting at an ITSP that is trying to > establish a call with extension 202. > Consider another phone (lets say extension 206) that attempts to do a > call pickup while phone 202 is Ringing. > 206 sends sipxbridge an INVITE with SDP OFFER and a Replaces header. > [ Note at this point that the ITSP is currently trying to establish > a call with 202 so the SDP answer has not gone back from 202. ] > > sipxbridge, sends back an SDP offer to 206 in the OK using the SDP > offer from the ITSP. > > I would expect at this point that 206 would answer with an SDP ANSWER > in the ACK but it responds to sipxbridge with ACK with no SDP.
A nasty situation indeed... As Robert has mentioned, 206 sends an offer to sipXbridge (inside) in the INVITE/Replaces, and sipXbridge's 200 contains the answer. 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. 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
