Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:ngw1.carrier.com;user=phone>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=”***”
Content-Length: 318--***
Content-Type: application/sdpv=0
o=GATEWAY1 2890844527 2890844527 IN IP4 gatewayone.carrier.com
s=-
c=IN IP4 gatewayone.carrier.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000--***
Content-Type: mime/isup7452a43564a4d566736fa343503837f168a383b84f706474404568783746463ffCompared to the example INVITEof Message 2 of Figure 11.3 shown previ-
ously, the message body is now a multipart MIME attachment. The first part
contains the SDP of the gateway, while the second part contains the binary
encoded IAM of Message 1 in Figure 11.4. In creating the IAM of Message 3 in
Figure 11.4, the terminating SIP-T gateway uses information from both the SIP
headers of the INVITEand the ISUP attachment.
In a SIP-T network, the complexity and intricacies of the PSTN are not
absorbed in the gateways, but distributed throughout the network. All gate-
ways must be able to parse the ISUP attachments, or true ISUP transparency
will not occur. For international networks, there are many different incompat-
ible “flavors” of ISUP. International gateway PSTN switches are extremely
complicated and expensive because of the requirements that they be able to
use and convert all these different incompatible protocols. In an international
SIP-T network, what “flavor” of ISUP will be used? If multiple versions are
allowed in the SIP network, every gateway will need to be able to deal with all
versions of ISUP. If only a single version is allowed, there will be information
loss as the ISUP is converted, leading to a failure in true transparency.
Finally, in a mixed SIP and SIP-T network (one involving SIP-T gateways,
conventional gateways, and SIP phones and end devices), the ISUP will need194 Chapter 11