On Wed, Mar 12, 2008 at 4:48 AM, Vikram Chhibber <[EMAIL PROTECTED]> wrote: > Raj, let me get this right. Are we attempting for a new sip response > code which explicitly means "I am busy and please try another sip > node" or do we want to standardize how a sip node discovers or get to > know the alternate path for signaling in case the attempted one is not > available? In the later case, as i have mentioned, SIP already has > procedures.
No. We're not reinventing RFC 3263. I'll quote the statement made in the first email in this thread: "using SIP mechanisms to handle the situation where you want to send a call to a first PSTN gateway, and if the gateway is busy (*not* if the target phone is busy), retry using the second gateway." > > > > On Wed, Mar 12, 2008 at 1:54 PM, Raj Jain <[EMAIL PROTECTED]> wrote: > > On Wed, Mar 12, 2008 at 2:11 AM, Vikram Chhibber > > <[EMAIL PROTECTED]> wrote: > > > I am not very sure of the need for this as in my opinion SIP already > > > has ways to achieve this. > > > > I disagree. > > > > > > If the gateway sends say 503, the proxy can > > > try another gateway. > > > > That's exactly the problem - let's "say" gateway sends 503, then proxy > > "can" try another gateway. We need a *definitive* way to that tell the > > proxy that there is congestion in the UAS or the downstream network > > and a separate route must be attempted. > > > > > > The gateway can itself redirect to the new > > > gateway by sending 302 response. > > > > One gateway has no idea about other gateways. > > > > > > > The proxy can get multiple gateway addresses by some proprietary > > > routing mechanism or say from the redirect server sending 300 response > > > or DNS/ENUM procedures. Then, the proxy can try sequentially these > > > gateways if the gateway in question does not respond in time. The only > > > concern is that if the gateway being tried is down, the proxy need not > > > wait for 408 (T1*64 sec.) which I believe is too long. Here I see a > > > need for introducing some standard timer say "inter-fork-terminal" > > > timer. > > > > I don't see what the above has to do with the discussion at hand. > > > > > > > > > > On Tue, Mar 11, 2008 at 11:02 PM, <[EMAIL PROTECTED]> wrote: > > > > From: "Raj Jain" <[EMAIL PROTECTED]> > > > > > > > > > > > > Definitely. We had to implement a proprietary SIP extension to > solve > > > > this problem in our system. > > > > > > > > Probably unavoidable... > > > > > > > > > > > > I'm also at the IETF. Perhaps we can meet and exchange notes. > > > > > > > > I'm sitting in the BLISS session, toward the front. Why don't we > meet > > > > at the break after BLISS? You can call me on my mobile at +1 617 > 538 4943. > > > > > > > > Dale > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip-implementors mailing list > > > > Sip-implementors@lists.cs.columbia.edu > > > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > > > > > > > > > > > > > > -- > > Raj Jain > > > > mailto:rj2807 at gmail dot com > > sip:rjain at iptel dot org > > > -- Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
