I believe it actually establishes the dialog with the partial digits. Then the dialog is modified with the new digits as they are received. I haven't tested this in a lab, so I can't be 100% sure, but that is what I've been led to believe.
As to your question about how many digits must be sent at minimum, depending on the calling plan... I'm not sure, but I believe most carriers would negotiate using a E.164 dialing plan which will give you enough information to properly start call routing even with partial digits. That's what I do with most (all but one) of my carrier interconnects. Joel Gerber Network Specialist Network Operations Eastlink E: [email protected] T: 519.786.1241 -----Original Message----- From: Paul Kyzivat [mailto:[email protected]] Sent: July-16-13 11:39 AM To: [email protected] Subject: Re: [Sip-implementors] Overlap signaling in a native SIP network The problem with the INFO method is that you first must establish a dialog with *something*, and you need a URI do do that. And once you have established that dialog, all the digits you send with INFO are going to it. So this really only works with certain topologies, and with the calling device having policies about how many digits it needs to construct that initial URI. So, suppose you have built a phone that is deployed in the US. And then the user of the phone calls an international number - say a room in a hotel in Germany. Does your phone have a dial plan for Germany? How many digits should it collect before sending the INVITE? Based on those digits, what server (if any) will you land on? Thanks, Paul On 7/16/13 10:08 AM, SIP Learner wrote: > Thanks to all! > > > I found one internet draft that propose to use the INFO method to convey > subsequent dialed numbers: > > > http://tools.ietf.org/id/draft-zhang-sipping-overlap-01.txt > > > It claimed to resolve the issues related to the INVITE/484/ACK approach in > RFC3578, but this draft seems to be deceased only after one revision, don't > know what's wrong with it! > > > > > ------------------ Original ------------------ > From: "Brett Tate"<[email protected]>; > Date: Tue, Jul 16, 2013 07:56 PM > To: "SIP Learner"<[email protected]>; > "sip-implementors"<[email protected]>; > > Subject: RE: [Sip-implementors] Overlap signaling in a native SIP > network > > > >> In my opinion, if only a SIP network is involved and no gateways are >> used, overlap signalling (e.g., the caller sends dialed digits to an >> outbound proxy in consecutive separate INVITEs for the outbound proxy >> to collect enough information and route the requests) is meaningless, >> because there are no physical connections to be established, am I >> right? > > It isn't meaningless; it wastes network resources and the devices would need > to agree upon what should occur (i.e. how the digits are collected, et > cetera). > > Even though draft-ietf-bliss-shared-appearances provides a PUBLISH mechanism > for seizing an appearance, some vendors might also allow an INVITE/484/ACK > exchange to temporarily keep an appearance seized. > _______________________________________________ > 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
