Re: SIP-T and Q.Sig

[Daniel Golding <dgolding@burtongroup.com>]

Which services are you offering your clients on the far side of the SBC?
VoIP Transit? Is the SIP signaling sufficient to provide all the
functionality you want?

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?

- 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



--
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/>.