[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIP-T and Q.Sig
On Mon, Jun 14, 2004 at 03:32:58PM -0400, Daniel Golding reportedly typed:
>
> Which services are you offering your clients on the far side of the SBC?
Our existing product offering is a carrier level product that allows
a carrier customer to send a voice call over IP to globalcrossing for
termination to the PSTN, which we then bill them on a per-minute basis.
There are many many other associated products and features in development
that will be available later this year.
> VoIP Transit? Is the SIP signaling sufficient to provide all the
> functionality you want?
So far, but it's still early. We don't yet have enough operational
experience with these protocols to know for sure. The one issue that
I pointed out previously with translation of term codes to SIP error
messages is not a problem we have run into operationally because
we don't yet send calls to other carriers via IP. We are anticipating
the problem, however.
> I guess that I'm wondering what the drivers are for things like SIP-T and
> Q.Sig when used between VoIP domains. If SIP does the trick on its own, are
> these other protocols needed?
I know very little about either of these efforts, so take this with a grain
of salt, but SIP-T may have been to address the lack of specificity of
SIP to the inter-switch carrier voice world, as much as Q.Sig was created
to address a lack of specificity of SIP to the Enterprise Inter-PBX world.
If there were very serious deficiencies, I would think that our carrier
customers would be pounding on us for SIP-T support, but I haven't seen
this. It must be that SIP is fairly adequate for now...but once the
minutes start to really ramp up, perhaps we will see a need for better
error handling. My personal preference would be to see SIP improved
to have better error handling, and perhaps the SIP forum could work
on the architecture for mapping SS7 messages to SIP messages in a way
that the proper failure handling could occur.
If Q.Sig was such a big deal, it would have shown up as a development
requirement for our Enterprise VoIP offering, but again, haven't seen
it requested, despite the fact that we're working on managed dial plan
sorts of offerings, that would put us in between a customers PBX's as
they were distributed among different locations.
I would love to hear other people's experiences and perspectives on
SIP-T and Q.Sig...I simply don't have a lot of experience to draw upon.
Dave
>
> - Dan
>
> On 6/14/04 2:59 PM, "Dave Siegel" <dave@siegelie.com> wrote:
>
> > On Mon, Jun 14, 2004 at 02:42:55PM -0400, Daniel Golding reportedly typed:
> >> Thanks, Dave.
> >>
> >> When connecting different vendor's softswitches together, what is the common
> >> signaling now? Q.sig? IAX2?
> >
> > We only use a softswitch from one vendor on the internal network, which
> > is the SONUS PSX/GSX, and we have it configured for SIP (but of course
> > it also uses Diameter+, a SONUS proprietary signalling protocol).
> >
> > We have a session border controller that sits between us and our VoIP
> > customers, which supports only SIP today but will support H.323 in the
> > future.
> >
> > IAX, or Inter-Asterisk eXchange, is only supported on Asterisk IP-PBX's
> > to my knowledge. I have played with it a bit on my home Asterisk box,
> > but it is largley a toy protocol at this point. I do get a sense that
> > it might be the makings of an underground Internet VoIP cloud, however.
> > It'll be interesting to see where that one goes.
> >
> > Dave
> >
> >>
> >> Or is so little of that going on, that there is no baseline?
> >>
> >> Thanks,
> >> Dan
> >>
> >> On 6/14/04 2:02 PM, "Dave Siegel" <dave@siegelie.com> wrote:
> >>
> >>> I don't know of anyone actually using SIP-T yet, although many list it
> >>> on their supported features list.
> >>>
> >>> My understanding of SIP-T is that it is nothing more than an SS7 message
> >>> encapsulated inside of a SIP message.
> >>>
> >>> This could be particularly useful for VoIP gateways, as the Term Codes used
> >>> in the Voice world do not map well to SIP error messages. For example,
> >>> there are three different term codes that map to a SIP 404 Not Found
> >>> error, but in the voice world, 2 of those codes should result in a
> >>> incompleted call, where as the 3rd would result in an alt route. If
> >>> the downstream that generated the error message was a VoIP Bridge and it
> >>> encapsulated the original SS7 message, the originating switch might have
> >>> a better idea of how to handle the failure scenario.
> >>>
> >>> Again, like I said, I'm not aware of anyone actually using it yet...I
> >>> wanted to keep quiet for a few days to see if anyone else spoke up first.
> >>>
> >>> Dave
> >>>
> >>> On Thu, Jun 10, 2004 at 02:09:04PM -0400, Daniel Golding reportedly typed:
> >>>>
> >>>> Can anyone shed light on the use of these protocols for inter-call server
> >>>> signaling? I've heard SIP-T is become prevalent for this, but the RFC seems
> >>>> to indicate that it was originally intended for SS7 to VoIP interoperation,
> >>>> rather than voip switch to voip switch signaling.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> --
> >>>> Daniel Golding
> >>>> Network and Telecommunications Strategies
> >>>> Burton Group
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> To unsubscribe send a message to voip-peering-request@psg.com with
> >>>> the word 'unsubscribe' in a single line as the message text body.
> >>>> An archive is at <http://psg.com/lists/voip-peering/>.
> >>
> >> --
> >> Daniel Golding
> >> Network and Telecommunications Strategies
> >> Burton Group
> >>
>
> --
> Daniel Golding
> Network and Telecommunications Strategies
> Burton Group
>
--
Dave Siegel http://www.siegelie.com/people/dsiegel/
Oro Valley, AZ
"Let us be thankful for the fools. But for them, the rest of
us could not succeed." -- Mark Twain
--
To unsubscribe send a message to voip-peering-request@psg.com with
the word 'unsubscribe' in a single line as the message text body.
An archive is at <http://psg.com/lists/voip-peering/>.