The Genband C20/CS2000 switch has an element called an SST that does the PSTN to SIP interworking. This is the device that supports using INFO messages for overlap dialing. It is acting as a gateway, hence its ability to send out the INFO messages during, I believe (I’m not 100% sure that it’s not performed during an early dialog, but I’m guessing it’s not), an already established dialog.
Now, that said, an SBC acting as a border element between 2 networks, operating as a B2BUA, is quite capable of handling post-dialog dialing by using re-INVITEs in one direction and INFO the other, as it is acting as a UAS and a UAC for the same dialog. Joel Gerber Network Administrator Network Operations Eastlink E: [email protected]<mailto:[email protected]> T: 519.786.1241 From: SIP Learner [mailto:[email protected]] Sent: July-16-13 10:46 AM To: Joel Gerber; sip-implementors Subject: Re:RE: [Sip-implementors] Overlap signaling in a native SIP network Is Genband's C20/CS2000 switches used as a gateway to PSTN and SIP network? or is it used as a pure SIP network element (proxy, B2BUA, etc)? If *only SIP is involved*, I can *not* figure out how the INFO method can be used to convey overlapping digits. INFO is sent within an early dialog created by the INVITE carrying the first dialed digits, if the INVITE is sent by the caller's UAC, with who will it create the dialog? According to RFC3261, a dialog is a relationship between UAs not between proxies or between a UA and a proxy (right?). Suppose the basic SIP trapezoid is used: UAC->Proxy1->Proxy2->UAS In a pure SIP network, if the caller UAC can create an early dialog with the callee UAS, the digits in the Request-URI *is* complete! (subsequent digits are not necessary because the UAS has been reached), so the UAC should *not* create the dialog with the UAS, and then how should the dialog be created? and between what elements? thanks! zhang ------------------ Original ------------------ From: "Joel Gerber"<[email protected]<mailto:[email protected]>>; Date: Tue, Jul 16, 2013 10:20 PM To: "SIP Learner"<[email protected]<mailto:[email protected]>>; "sip-implementors"<[email protected]<mailto:[email protected]>>; Subject: RE: [Sip-implementors] Overlap signaling in a native SIP network I know Genband's C20/CS2000 switches support (and default) to using the INFO method for overlapping digits (this is what they call partial dialled digits followed by subsequent digits). Joel Gerber Network Specialist Network Operations Eastlink E: [email protected]<mailto:[email protected]> T: 519.786.1241 -----Original Message----- From: SIP Learner [mailto:[email protected]] Sent: July-16-13 10:09 AM To: Brett Tate; sip-implementors Subject: Re: [Sip-implementors] Overlap signaling in a native SIP network 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]<mailto:[email protected]>>; Date: Tue, Jul 16, 2013 07:56 PM To: "SIP Learner"<[email protected]<mailto:[email protected]>>; "sip-implementors"<[email protected]<mailto:[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]<mailto:[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
