I'm connecting my customer (a 100-employees company in Switzerland) to one of the major service providers with a SIP trunk (this trunk would be the primary way to PSTN).
The SP puts forward a number of requirements, such as national/international context in To: field, then some special requirements for CallerID privacy, etc. The problem is, we can't get a document that describes the technical details of the interface, and SP refuses to create such a document. All we've got is a number of emails and some information from phone conversations. Also an example for a Cisco CUBE router and a Visio drawing with some IP addressing information.
Is it a common situation for such a service? Am I too naive with my expectations to receive a fully documented service? If it were a no-name lousy cheap service provider, I wouldn't ask :)
cheers, stan
Hello Stan
The SP puts forward a number of requirements, such as national/international context in To: field, then some special requirements for CallerID privacy, etc. The problem is, we can't get a document that describes the technical details of the interface, and SP refuses to create such a document. All we've got is a number of emails and some information from phone conversations.
SIP and its extensions are fairly well standardized. Have a look at http://www.packetizer.com/ipmc/sip/standards.html for an overview of those RFCs. We all know the PBX manufacturers and their developers seldom fully comply to the standards so they should give you a good starting point on how it's supposed to be done. You will have to test each and every case with your SP unless he can garantee you he has implemented it fully standard compliant.
Is it a common situation for such a service? Am I too naive with my expectations to receive a fully documented service? If it were a no-name lousy cheap service provider, I wouldn't ask :)
We never had any issues when connecting SIP trunks to a provider as long as they were using RFC compliant SIP (IMHO the RFC compliance is a major decision point when choosing the SP). And I second you on the point that the SP should document its extensions to the protocol if they are not standard compliant extensions.
Regards
Jean-Pierre
RFC compliance is not a problem, but still there are SP-specific requirements on how these RFCs are supported and what the SP expects from our side. Also important, what SP is going to send toward us :)
For example, the numbering plan. Calls to UK, for example, should not be 0044.*, but 44.* with phone-context=national. I've got this information via a phone conversation, and not in a written document.
Everything works now, I'm just wondering if it's a standard practice to deliver such a poor documentation.
From: Jean-Pierre Schwickerath swinog@hilotec.net To: swinog@lists.swinog.ch Cc: Stanislav Sinyagin ssinyagin@yahoo.com Sent: Thursday, August 18, 2011 10:52 AM Subject: Re: [swinog] SIP gateway service documentation
Hello Stan
The SP puts forward a number of requirements, such as national/international context in To: field, then some special requirements for CallerID privacy, etc. The problem is, we can't get a document that describes the technical details of the interface, and SP refuses to create such a document. All we've got is a number of emails and some information from phone conversations.
SIP and its extensions are fairly well standardized. Have a look at http://www.packetizer.com/ipmc/sip/standards.html for an overview of those RFCs. We all know the PBX manufacturers and their developers seldom fully comply to the standards so they should give you a good starting point on how it's supposed to be done. You will have to test each and every case with your SP unless he can garantee you he has implemented it fully standard compliant.
Is it a common situation for such a service? Am I too naive with my expectations to receive a fully documented service? If it were a no-name lousy cheap service provider, I wouldn't ask :)
We never had any issues when connecting SIP trunks to a provider as long as they were using RFC compliant SIP (IMHO the RFC compliance is a major decision point when choosing the SP). And I second you on the point that the SP should document its extensions to the protocol if they are not standard compliant extensions.
Regards
Jean-Pierre
-- HILOTEC Engineering + Consulting AG - Langnau im Emmental Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs Tel: +41 34 402 74 00 - http://www.hilotec.com/
in that example, I meant phone-context=international, of course :)
From: Stanislav Sinyagin ssinyagin@yahoo.com To: Jean-Pierre Schwickerath swinog@hilotec.net; "swinog@lists.swinog.ch" swinog@lists.swinog.ch Sent: Thursday, August 18, 2011 11:29 AM Subject: Re: [swinog] SIP gateway service documentation
RFC compliance is not a problem, but still there are SP-specific requirements on how these RFCs are supported and what the SP expects from our side. Also important, what SP is going to send toward us :)
For example, the numbering plan. Calls to UK, for example, should not be 0044.*, but 44.* with phone-context=national. I've got this information via a phone conversation, and not in a written document.
Everything works now, I'm just wondering if it's a standard practice to deliver such a poor documentation.
From: Jean-Pierre Schwickerath swinog@hilotec.net To: swinog@lists.swinog.ch Cc: Stanislav Sinyagin ssinyagin@yahoo.com Sent: Thursday, August 18, 2011 10:52 AM Subject: Re: [swinog] SIP gateway service documentation
Hello Stan
The SP puts forward a number of requirements, such as national/international context in To: field, then some special requirements for CallerID privacy, etc. The problem is, we can't get a document that
describes the technical details of the interface, and
SP refuses to create such a document. All we've got is a number of emails and some information from phone conversations.
SIP and its extensions are fairly well standardized. Have a look at http://www.packetizer.com/ipmc/sip/standards.html for an overview of those RFCs. We all know the PBX manufacturers and their developers seldom fully comply to the standards so they should give you a good starting point on how it's supposed to be done. You will have to test each and every case with your SP unless he can garantee you he has implemented it fully standard compliant.
Is it a common situation for such a service? Am I too naive with my expectations to receive a fully documented service? If it were a no-name lousy cheap service provider, I wouldn't ask
:)
We never had any issues when connecting SIP trunks to a provider as long as they were using RFC compliant SIP (IMHO the RFC compliance is a major decision point when choosing the SP). And I second you on the point that the SP should document its extensions to the protocol if they are not standard compliant extensions.
Regards
Jean-Pierre
-- HILOTEC Engineering + Consulting AG - Langnau im Emmental Energietechnik und Datensysteme: Server, PCs, Linux, Telefonanlagen, VOIP, Hosting, Datenbanken, Entwicklung, Komplettlösungen für KMUs Tel: +41 34 402 74 00 - http://www.hilotec.com/
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
-
Jean-Pierre Schwickerath -
Stanislav Sinyagin