Sorry; dialog being modified wasn't the most accurate terminology. The way I understand the workings in the Genband environment, the subsequent (and preceeding) digits are sent in an INFO message either during the provisional stage of dialog setup or after the dialog is fully established. I think it's after it is fully established, but I don't know this for 100%. And, yes, I've only seen this used in an ISUP to SIP gateway environment.
E.164 is an ITU-T specification that defines how digits are to be represented when being signaled between switching devices. In basic, the format is a string always preceeded with a `+`, then the country code, and then the rest of the digits as defined by the local dialing plan. IE: +15197861241 for my phone number. This is a standard that is pretty much always followed for international calls, and is becoming common for calls between carriers even if they are in the same calling area when they are peering with SIP. With E.164, you are guaranteed(-ish) a globally unique number, which can make call routing simpler, especially when you want to be able to make a quick determination on the routing path to take without necessarily having to translate on all of the digits. 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 3:27 PM To: Joel Gerber Cc: [email protected] Subject: Re: [Sip-implementors] Overlap signaling in a native SIP network On 7/16/13 1:41 PM, Joel Gerber wrote: > 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. What do you mean "dialog is modified"??? I see how this can work if the initial sip signaling reaches a gateway to a network that supports digit by digit dialing. But I don't see how this would work in an all-sip network. > 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. And what is an E.164 dial plan? Does it have a plan for every country code? AFAIK most systems handle this via a timeout on the dialing and then do en bloc. Thanks, Paul > 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
