> > > > So it doesn't seem that you will ever need to expend additional effort > > to get 484s to work correctly. > > Its worse than that. The GW may have opened up a pstn connection based > on the partial number, and received info back which results in the 484. > The retry with more digits needs to reach the gw that still has that state. > > Somebody with some actual understanding of the PSTN will have to elaborate further.
That is eactly right. The collection of digits is clearly a stateful thing but the 484 mechanism is not stateful at all. And this causes all the problems. But the RFC 3578 tries to get around this problem by saying that the first INVITE and all subsequent ones must get forwarded to the same PSTN gateway. But this is not very helpful. One way around this is for the SIP router to do some kind of hashing on the INVITE's call-id (which, of course, should be the same for all INVITEs of the same call), then use the random number obtained in conjunction with the DNS SRV weighting to make sure that each INVITE gets forwarded to the same place. And the INVITE/484 interaction described in RFC3578 section "3.5.SIP to ISUP" is very uncomfortable for me. When a gateway receives a subsequent INVITE with the same Call-ID and From tag as the previous one, and an updated Request-URI, a SAM should be generated as opposed to a new IAM. Upon reception of a subsequent INVITE, the INVITE received previously is answered with 484 Address Incomplete. So you send out each new INVITE without waiting for the previous INVITE to complete!! In my opinion it would have been better for a dialog to get set up first and then for the digits to be collected using the same Route. My idea is that for each digit received, you'd effectively create a new fork. And when you get the next INVITE, you release the previous one by using Christer's 199 response. or something like that. Attila -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: 05 March 2008 13:46 To: [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Sip-implementors] "484 Address Incomplete" - overlap dialling- ensuring all messages go to same PSTN gateway (RFC3578) Dale, at end... [EMAIL PROTECTED] wrote: > From: "Attila Sipos" <[EMAIL PROTECTED]> > > > What if you are using something like DNS SRV to route to a > > group of gateways? How can one ensure all new requests go the > > same gateway? > > > >Why would you want to? > > Maybe I wasn't clear. > > I want all the overlapped dialling related to single call to all go > to the same gateway. This is what RFC3578 requires anyway but it > does this by saying you can only use overlap dialling in the way > described if "the SIP routing infrastructure ensures that INVITEs > will only reach one gateway." > > What if you have a pool of PSTM gateways? For example, you have 1 > gateway at first but you need more capcity. > > Yes, I see that's what RFC 3578 says. But it's clear if you think > about it that the real requirement is "All INVITEs reach one of a set > of gateways/proxies that all have the same policy in regard to which > URIs will receive 484 responses." > > And in any situation that makes sense from an engineering point of > view, that latter condition will be true without additional effort in > regard to 484 responses. > > So it doesn't seem that you will ever need to expend additional effort > to get 484s to work correctly. Its worse than that. The GW may have opened up a pstn connection based on the partial number, and received info back which results in the 484. The retry with more digits needs to reach the gw that still has that state. Somebody with some actual understanding of the PSTN will have to elaborate further. Paul _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
