<abalashov@evaristesys.com> wrote:
>> They are variants of SIP, and as such they would require a proper
>> protocol stack to support. More at the end on this.
>
> I think I misspoke. What I meant was that because Asterisk does not
> have a protocol stack for these, it will not "support" them in the sense
> that it will neither (1) take advantage of their features or provide any
> features specific to those implementations, or (2) pass / tunnel those
> protocols passively. In the latter case, being a B2BUA does have a lot
> to do with that.
Actually, SIP-T and SIP-I are simply extensions of the SIP protocol,
not new protocols themselves. All they define is a mechanism to carry
an actual binary ISUP message as a MIME body part within a SIP message
and some SIP/ISUP interworking behavior. Carrying ISUP within SIP is
no different from carrying, let's say, SDP within SIP as far as the
structure of the SIP protocol goes. The SIP state machinery, which is
what a SIP protocol stack such as chan_sip.c implements, is still the
same.
If you think of Asterisk as a Softswitch (implemented as a SIP B2BUA),
it could possibly be sitting between two SIP/SS7 gateways, and in
principle it can dip inside the ISUP payload and make service
decisions based on that. At the least, it should be able to tunnel the
payload from one call leg to another. This would actually be pretty
useful as a generic capability to tunnel any type of payload across
the two legs of B2BUA.
--
Raj Jain
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
Posts
No comments:
Post a Comment