> -----Original Message----- > From: M. Ranganathan [mailto:[email protected]] > Sent: Wednesday, March 24, 2010 9:26 AM > To: CHU, XINGJUN (XINGJUN) > Cc: WORLEY, DALE R (DALE); [email protected]; sipx- > [email protected] > Subject: Re: [sipX-dev] SLOW START on SIPX > > On Wed, Mar 24, 2010 at 8:52 AM, CHU, XINGJUN (XINGJUN) > <[email protected]> wrote: > > > > > >> -----Original Message----- > >> From: [email protected] [mailto:sipx-dev- > >> [email protected]] On Behalf Of M. Ranganathan > >> Sent: Tuesday, March 23, 2010 2:26 PM > >> To: WORLEY, DALE R (DALE) > >> Cc: [email protected]; [email protected] > >> Subject: Re: [sipX-dev] SLOW START on SIPX > >> > >> On Tue, Mar 23, 2010 at 2:11 PM, WORLEY, DALE R (DALE) > >> <[email protected]> wrote: > >> > ________________________________________ > >> > From: [email protected] [sipx-dev- > >> [email protected]] On Behalf Of M. Ranganathan > >> [[email protected]] > >> > > >> > If a dialog forming INVITE without SDP is sent to sipxbridge it > will > >> > return 400 error. (at least it should return a 400 error). > >> > > >> > The first reason is that sipxbridge is a B2BUA and not just a UA > and > >> > hence does not as such support an a-priori known codec set. > >> > _______________________________________________ > >> > > >> > How difficult would it be to enhance sipXbridge to postpone the > >> response to the INVITE it receives until it receives the response to > >> the INVITE it sends, so that it can carry the SDP it received from > the > >> outbound far-end? > >> > >> > >> SipXbridge currently does not respond to the INVITE immediately. It > >> sends a trying and forwards the INVITE to the far end. So other than > >> suppressing the 400 it requires really no additional work. The > >> complication is in the way the relays are allocated. > > > > What is the complication?
I should've say what's the difference in terms of allocating relay between the "fast start" and " slow start" scenario? what prevent it happening before? > > > Please read below : > > > > > >> > >> The logic would need to be changed to allocate a relay on the > response > >> to the INVITE rather than the initial outbound INVITE. This would > >> require a bit of hacking and testing. Not difficult but I'd say > about > >> a week's exercise all told (bugs and all). > >> > >> Ranga > >> > >> > >> > > >> > Dale > >> > > >> > >> > >> > >> -- > >> M. Ranganathan > >> _______________________________________________ > >> sipx-dev mailing list [email protected] > >> List Archive: http://list.sipfoundry.org/archive/sipx-dev > >> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > >> sipXecs IP PBX -- http://www.sipfoundry.org/ > > > > > > -- > M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
