[SIPForum-discussion] SIP to ISUP mapping

[Raghul Prasanna]

So folks, what is it then, choose the best that suites you is it?


________________________________
 From: "Calme, James A (Jim)" <jim.calme at alcatel-lucent.com>
To: Raghul Prasanna <raghul82 at yahoo.co.uk> 
Sent: Thursday, 7 June 2012, 14:13
Subject: RE: [SIPForum-discussion] SIP to ISUP mapping
 

 
Welcome to my nightmare!
 

________________________________
 
From:discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of  Raghul Prasanna
Sent: Monday, June 04, 2012 6:53 PM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] SIP to ISUP mapping
 
Hello,
 
I was looking at standards for SIP to ISUP and ISUP to SIP mapping and found the following
 
* RFC 3398 (IETF)
* RFC 3372 (SIP T) IETF
* Q 1912.5 (which talks about SIP profile A, B and C (SIP I)) ITU.
 
SIP I and SIP T defines the std for ISUP encapsulation and translation.
 
The rest I believe says mainly about ISUP -> SIP and SIP -> ISUP mapping.
 
RFC 3398 introduces the concept of SIP bridging two PSTN networks and says gateways bordering PSTN SIP network can encapsulate ISUP message etc.
 
In ISUP to SIP network, we can encapsulate the ISUP message, but on a SIP to ISUP network we have to map the SIP messages (fields) to ISUP messages (fields). In order to do this which std will a gateway follow?
 
 
Why do we have so many standards? Did some of them get superseded, which I believe can be because 3398 was formulated in 2002 while 1912.5 in 2004. Is that correct?
 
If all are in use, who follows which standard or does it depend on vendor? Until now I believed Q1912.5 was the bible for SIP <-> ISUP mapping and gateways can apply either SIP I or do standard mapping depending on requirements, which I believe is not correct.
 
To be honest I am lost a bit after going through the above standards.
 
Can someone shed some light please?
 
Thanks,
Raghul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20120607/c8901dd8/attachment-0002.html>