SIP
Click on the red underlined text to get to the source
... ISUP and the network carrying SIP. The MGC also has some
capabilities for controlling the voice ...
... This document describes logic and procedures which an MGC might use
to implement the mapping between SIP and ISUP by illustrating the
correspondences, at the message level and parameter level, between
...
...
This document focuses on the translation of ISUP messages into SIP
messages, and the mapping of ISUP parameters into SIP headers ...
... ISUP messages into SIP
messages, and the mapping of ISUP parameters into SIP headers. For
ISUP ...
... headers. For
ISUP calls that traverse a SIP network, the purpose of translation is
to allow SIP elements such as proxy servers ...
... ISUP calls that traverse a SIP network, the purpose of translation is
to allow SIP elements such as proxy servers (which do not typically
understand ISUP ...
... ISUP criteria
such as the called party number. This document consequently provides
a SIP mapping only for those ISUP parameters which might be used by
intermediaries in the routing ...
... ISUP parameters which might be used by
intermediaries in the routing of SIP requests. As a side effect of
this approach, translation also increases the overall
interoperability ...
... interoperability by providing critical information about the call to
SIP endpoints that cannot understand encapsulated ISUP, or perhaps
...
... PSTN trunks are treated only
as far as they affect the control of an ongoing call; otherwise these
messages neither have nor require any analog in SIP.
Messages indicating error or congestion ...
... described in this document are presented as an optional mechanism.
Mapping of SIP headers to ISUP parameters in this document focuses
...
... Initial Address Message (IAM) and the headers associated with the SIP
INVITE message; both of these messages are used in their respective
...
... headers. Hence, the problem of parameter-to-
header mapping in SIP-T is confined more or less to the IAM and the
INVITE ...
... ISUP messages Address Complete Message (ACM) and
Release Message (REL) based on SIP status codes.
...
... status codes.
This document describes when the media path associated with a SIP
call is to be initialized, terminated, modified, etc., but it does
not go into details such as how the initialization ...
...
There are several scenarios where ISUP-SIP mapping takes place. The
way the messages are generated is different depending on the
scenario.
...
...
When there is a single MGC and the call is from a SIP phone to a PSTN
phone, or vice versa, the MGC ...
...
The scenario where a call originates in the PSTN, goes into a SIP
network and terminates in the PSTN again is known as "SIP bridging ...
... PSTN, goes into a SIP
network and terminates in the PSTN again is known as "SIP bridging".
SIP ...
... switches handling the call. This is achieved by encapsulating the
incoming ISUP messages in the body of the SIP messages (see [3]). In
this case, the ISUP ...
... ISUP messages generated by the egress MGC are the ones
present in the SIP body (possibly with some modifications; for
example, if the called number in the request Uniform Resource
Identifier - URI ...
... URI - is different from the one present in the ISUP due
to SIP redirection, the ISUP message will need to be adjusted).
...
... +------+ +-------------+ +-----+ +------------+ +------+
SIP is used in the middle of both MGCs because the voice path has to
be established through the IP network ...
... be established through the IP network between both MGs; this
structure also allows the call to take advantage of certain SIP
services. ISUP ...
... services. ISUP messages in the SIP bodies provide further
information (such as cause values and optional parameters) to the
...
... MGC places the incoming ISUP messages
in the SIP body by default. Note that this has security
implications; see Section 15. If the recipient of these messages
(typically a SIP User Agent ...
... SIP body by default. Note that this has security
implications; see Section 15. If the recipient of these messages
(typically a SIP User Agent Client/User Agent Server - UAC ...
... UAS) does
not understand them, a negotiation using the SIP 'Accept' and
'Require' headers will take place and they will not be included in
...
... 'Require' headers will take place and they will not be included in
the next SIP message exchange.
There can be a Signaling Gateway ...
... timers to insure that all digits have been
collected before an INVITE is transmitted to a SIP network.
In some instances, gateways ...
... ISUP message. An
incomplete message may not contain sufficient parameters to allow for
a proper mapping to SIP; similarly, encapsulating (see below) an
incomplete ISUP message may be confusing to terminating gateways ...
... SIP Mechanisms Required ...
...
For a correct mapping between ISUP and SIP, some SIP mechanisms above
and beyond those available in the base SIP ...
... For a correct mapping between ISUP and SIP, some SIP mechanisms above
and beyond those available in the base SIP specification are needed.
...
... SIP, some SIP mechanisms above
and beyond those available in the base SIP specification are needed.
These mechanisms are discussed below. If the SIP UAC ...
... and beyond those available in the base SIP specification are needed.
These mechanisms are discussed below. If the SIP UAC/UAS involved in
...
... PSTN to PSTN across a SIP network, SIP messages MUST be capable of
transporting ISUP payloads ...
... 3].
SIP user agents which do not understand ISUP are permitted to ignore
these optional MIME ...
... In most PSTN interworking situations, SIP message bodies will be
required to carry session information (Session Description Protocol ...
... by the user are transmitted by a gateway is
completely orthogonal to how SIP and ISUP are interworked; however,
as DTMF ...
... Early media denotes the capability to play media (audio for
telephony) before a SIP session has been established (before a 2xx
response code ...
... user agents prepare themselves to receive backwards media as soon as
an INVITE transmitted, the baseline SIP protocol has enough support
to enable rudimentary unidirectional early media ...
... PSTN, there are situations when gateways
will need to send messages to each other over SIP that do not
correspond to any SIP operations.
...
... will need to send messages to each other over SIP that do not
correspond to any SIP operations.
In support of mid-call transactions ...
... transactions and other ISUP events that do not
correspond to existing SIP methods, SIP gateways ...
... caller in some fashion.
The base SIP protocol supports a method of specifying that a user is
anonymous. However, this system has a number of limitations - for
...
... ISUP to signal that you would like to discontinue
an attempt to set up a call - the general-purpose REL is sent in the
forwards direction. There is a similar concept in SIP - that of a
CANCEL request that is sent in order to discontinue the establishment
of a SIP dialog ...
... SIP - that of a
CANCEL request that is sent in order to discontinue the establishment
of a SIP dialog. For various reasons, however, CANCEL requests
cannot contain message bodies, and therefore in order to carry the
...
... exceptional conditions, like catastrophic network failure, a REL may
be sent with a different cause code, and it would be handy if a SIP
network could carry the cause code end-to-end. Therefore gateways
...
... state machines. One state machine handles calls from
SIP to ISUP and the second from ISUP to SIP ...
... SIP to ISUP and the second from ISUP to SIP. There are details, such
as some retransmissions and some states (waiting for the Release
Complete ...
... retransmissions and some states (waiting for the Release
Complete Message - RLC, waiting for SIP ACK etc.), that are not shown
in the figures in order to make them easier to follow.
...
... success and error cases when setting up a call initiated from the SIP
network. "100 Trying" acknowledgements to INVITE requests are not
displayed below although they are required in many architectures ...
...
4. The "called party status" code in the ACM message is mapped to a
SIP provisional response (as described in Section 7.2.5 and
Section 7.2.6) and returned to the SIP node ...
... SIP provisional response (as described in Section 7.2.5 and
Section 7.2.6) and returned to the SIP node. This response may
contain SDP ...
... 6. Upon receipt of a CPG message, the gateway will map the event
code to a SIP provisional response (see Section 7.2.9) and send
it to the SIP node ...
... SIP Timeout ...
... 4. Upon receipt of the ANM, the gateway will send a 200 message to
the SIP node and set SIP timer ...
... expiry).
7. A BYE is transmitted to the SIP node in an attempt to close the
call. Further handling for this clean up is not shown, since the
...
... node in an attempt to close the
call. Further handling for this clean up is not shown, since the
SIP node's state is not easily known in this scenario.
...
...
5. The gateway translates the cause code in the REL to a SIP error
response (see Section 7.2.4) and sends it to the SIP node ...
... gateway translates the cause code in the REL to a SIP error
response (see Section 7.2.4) and sends it to the SIP node.
...
... parameter), the gateway will generate a 183 message towards the
SIP node; this contains SDP to establish early media ...
... 5. A final INVITE response, based on the cause code received in the
earlier ACM message, is generated and sent to the SIP node to
terminate the call. See Section 7.2.4.1 for the table which
...
... node to
terminate the call. See Section 7.2.4.1 for the table which
contains the mapping from cause code to SIP response.
6. Upon expiration of the interwork timer ...
... PSTN node to terminate the call. Note that the SIP node can also
terminate the call by sending a CANCEL before the interwork timer ...
... Call Canceled by SIP ...
...
4. The "called party status" code in the ACM message is mapped to a
SIP provisional response (as described in Section 7.2.5 and
Section 7.2.6) and returned to the SIP node ...
... SIP provisional response (as described in Section 7.2.5 and
Section 7.2.6) and returned to the SIP node. This response may
contain SDP ...
... INVITE request is received by the gateway, a "100 Trying"
response MAY be sent back to the SIP network indicating that the
gateway is handling the call.
...
... 17] lists 29 in all. However, each of these
parameters need not to be translated in order to achieve the goals of
SIP-ISUP mapping. As is stated above, translation allows SIP network
...
... SIP-ISUP mapping. As is stated above, translation allows SIP network
elements to understand the basic PSTN ...
... encapsulated
ISUP, the relevant values of SIP header fields MUST 'overwrite'
through the process of translation the parameter values that would
...
... basic services,
including various sorts of call forwarding and redirection, to be
implemented in the SIP network.
For example, if an INVITE ...
... gateway will send to the PSTN. Further details of how SIP header
fields are translated into ISUP parameters follow.
...
... CIP should be used in other cases.
When a SIP call has been routed to a gateway, then the Request-URI
...
... Request-URI
will most likely contain a tel URL (or a SIP URI with a tel URL user
portion) - SIP ...
... telephone number, as will sometimes be the case if a call originated
at a SIP phone that employs a SIP URI user@host convention. The CIN
...
... telephone number, as will sometimes be the case if a call originated
at a SIP phone that employs a SIP URI user@host convention. The CIN
parameter SHOULD be omitted from the outbound IAM ...
... gateway implementers MAY
consider some non-standard way of mapping particular SIP URIs to
telephone numbers ...
... Access indicator to 'Originating access non-ISDN' (generally, it is
not safe to assume that SIP phones will support ISDN endpoint
...
... ISUP is not
present; however, doing so may significantly limit the efficiency and
transparency of SIP-ISUP translation.
...
... User to user service 3 can be requested by the callee also. In non-
SIP bridging situations, the MGC should be capable of rejecting this
...
... MG are released. A '504 Server Timeout' SHOULD be sent back to the
SIP network. A REL message with cause value 102 (protocol error,
recovery on timer ...
... expect the PSTN to respond with RLC and the SIP network to respond
with an ACK indicating that the release sequence has been completed.
...
...
If a CANCEL or BYE request is received before a final SIP response
has been sent, a '200 OK' MUST be sent to the SIP network to confirm
...
... If a CANCEL or BYE request is received before a final SIP response
has been sent, a '200 OK' MUST be sent to the SIP network to confirm
the CANCEL or BYE; a 487 MUST also be sent to terminate the INVITE
...
... release sequence is complete.
In SIP bridging situations, a REL might be encapsulated in the body
...
...
This section applies when a REL is received before a final SIP
response has been sent. Typically, this condition arises when a call
has been rejected by the PSTN ...
... bridging case) - therefore, the REL message just received SHOULD be
included in the body of the SIP response. The gateway SHOULD NOT
return a response with encapsulated ...
... SS7 network is very general,
whereas SIP has a number of specific tools that, collectively, play
the same role ...
... setup request (IAM) that has just been received (corresponding to a
SIP status code).
Note that it is not necessarily appropriate to map some ISDN ...
... Note that it is not necessarily appropriate to map some ISDN cause
codes to SIP messages because these cause codes are only meaningful
to the ISUP interface ...
... switch to re-send the IAM for a different CIC, not for the call to be
torn down. Clearly, there is not (nor should there be) an SIP status
code indicating that a new CIC should be selected - this matter is
internal to the originating gateway. Hence receipt of cause code 44
...
... gateway. Hence receipt of cause code 44
should not result in any SIP status code being sent; effectively, the
cause code is untranslatable.
...
... important distinction being between the user and the network). In
most cases, the cause location does not affect the mapping to a SIP
status code; some exceptions are noted below. A diagnostic field may
also be present for some ISDN causes; this diagnostic will contain
...
...
ISUP Cause value SIP response
---------------- ------------
1 unallocated number 404 Not Found
...
... diagnostic field. If the MGC is able to process this information it
SHOULD be added to the SIP response (301) in a Contact header.
...
...
ISUP Cause value SIP response
---------------- ------------
65 bearer capability not implemented 488 Not Acceptable Here
...
...
ISUP Cause value SIP response
---------------- ------------
87 user not member of CUG 403 Forbidden
...
... Progress response (see [1]) to the SIP network. In SIP bridging
situations (where encapsulated ...
... address is complete (ACM) creates known problems in SIP bridging
cases, and it SHOULD NOT therefore be sent.
...
... Most commonly, on receipt of an ACM a provisional response (in the
18x class) SHOULD be sent to the SIP network. If the INVITE that
initiated this session ...
... early media extension, that any necessary ringback tones will be
generated locally by the SIP user agent to which the gateway is
responding (which may in turn be a gateway ...
...
When an ANM or CON message is received, the call has been answered
and thus '200 OK' response SHOULD be sent to the SIP network. This
200 OK SHOULD contain an answer to the media offered in the INVITE.
...
... 200 OK SHOULD contain an answer to the media offered in the INVITE.
In SIP bridging situations (when the INVITE that initiated this call
...
... receiving
any ACM at all (when an automaton answers the call). In this
situation the SIP user will never have received a 18x provisional
response, and consequently they will not hear any kind of ringtone
before the callee answers. This may result in some clipping of the
...
... Unavailable' response code SHOULD be
sent to the SIP network, and an REL message with cause value 19 (no
answer from the user) SHOULD be sent to the ISUP network ...
... PSTN
can be expected to respond with an RLC and the SIP network to respond
with an ACK indicating that the release sequence has been completed.
...
... unidirectional backwards media path.
In SIP bridging situations (when the INVITE that initiated this
...
... 1. When a PSTN user wishes to begin a session with a SIP user, the
PSTN network generates an IAM ...
... 3. When an event signifying that the call has sufficient addressing
information occurs, the SIP node will generate a provisional
response of 180 or greater.
...
... ISUP CPG messages as indicated in Section 8.2.3.
7. When the SIP node answers the call, it will send a 200 OK
message.
...
... 1. When a PSTN user wishes to begin a session with a SIP user, the
PSTN network generates an IAM ...
... gateway generates an INVITE
message and sends it to an appropriate SIP node based on called
number analysis.
...
... number analysis.
3. Since the SIP node is set up to automatically answer the call, it
will send a 200 OK message.
...
... SIP Timeout ...
... 1. When a PSTN user wishes to begin a session with a SIP user, the
PSTN network generates an IAM ...
... gateway generates an INVITE
message, and sends it to an appropriate SIP node based on called
number analysis. The ISUP ...
... time the timer T1 expires. The SIP standard specifies that
INVITE transmission will be performed 7 times if no response is
...
...
6. The gateway also sends a CANCEL message to the SIP node to
terminate any initiation attempts.
...
... 1. When a PSTN user wishes to begin a session with a SIP user, the
PSTN network generates an IAM ...
... gateway generates an INVITE
message, and sends it to an appropriate SIP node based on called
number analysis. The ISUP ...
... time the timer T1 expires. The SIP standard specifies that
INVITE transmission will be performed 7 times if no response is
...
... INVITE transmission will be performed 7 times if no response is
received. Since SIP T1 starts at 1/2 second or more and doubles
...
... starts at 1/2 second or more and doubles
each time it is retransmitted, it will be at least a minute
before SIP times out the INVITE request; since SIP T1 ...
... before SIP times out the INVITE request; since SIP T1 is allowed
to be larger than 500 ms initially, it is possible that 7 x SIP ...
... SIP T1 is allowed
to be larger than 500 ms initially, it is possible that 7 x SIP
T1 will be longer than ISUP ...
... SIP Error Response ...
... 1. When a PSTN user wishes to begin a session with a SIP user, the
PSTN network generates an IAM ...
... gateway generates an INVITE
message, and sends it to an appropriate SIP node based on called
number analysis.
...
... SIP Redirection ...
... 1. When a PSTN user wishes to begin a session with a SIP user, the
PSTN network generates an IAM ...
... gateway generates an INVITE
message, and sends it to an appropriate SIP node based on called
number analysis.
...
... number analysis.
3. The SIP node indicates that the resource which the user is
attempting to contact is at a different location by sending a 3xx
...
... 7. When an event signifying that the call has sufficient addressing
information occurs, the SIP node will generate a provisional
response of 180 or greater.
...
... indicated in Section 8.2.3.
9. When the SIP node answers the call, it will send a 200 OK
message.
...
... 1. When a PSTN user wishes to begin a session with a SIP user, the
PSTN network generates an IAM ...
... gateway generates an INVITE
message, and sends it to an appropriate SIP node based on called
number analysis.
...
... 3. When an event signifying that the call has sufficient addressing
information occurs, the SIP node will generate a provisional
response of 180 or greater.
...
... indicated in Section 8.2.3.
5. If the calling party hangs up before the SIP node answers the
call, a REL message will be generated.
...
... INVITE message MUST
be created for transmission to the SIP network. This section details
the process by which a gateway populates the fields of the INVITE ...
... gateway SHOULD create a dummy From header field containing a SIP URI
without a user portion which communicates only the hostname of the
gateway ...
... early media session using some
SIP extension, see Section 5.5. If a gateway receives a 183 response
while it is playing backwards media, then when it generates a mapping
...
... PSTN as
well as an ACK to the SIP network.
If the 200 OK response arrives before the gateway ...
... URIs found in any Contact header field(s) present in
the response, as is mandated in the base SIP specification. Such 3xx
responses are typically sent by a redirect server, and can be thought
...
... normal PSTN switch (no SIP involved) - usually this will be the case
when the URI in the Contact header ...
... telephone number in the URI. If, however, the new location is
best reachable using SIP (if the URI in the Contact header contains
...
...
While it is exploring a long list of Contact header fields with SIP
requests, a gateway MAY send a CPG message with an event code of 6
(Forwarding) to the PSTN ...
...
ACK to the SIP network. Some specific circumstances are identified
below in which a gateway MAY attempt to rectify a SIP ...
... SIP network. Some specific circumstances are identified
below in which a gateway MAY attempt to rectify a SIP-specific
problem communicated by a status code without releasing the call by
...
... SIP Status Code to ISDN Cause Code Mapping ...
...
When a REL message is generated due to a SIP rejection response that
contains an encapsulated REL message, the Cause Indicator (CAI)
...
... SIP
extensions, versions of SIP subsequent to the issue of this document,
or simply omitted) should be mapping to cause code 31 "Normal,
unspecified". These mappings cover only responses; note that the BYE
...
... ISDN cause codes that are ISUP-specific and
have no corollary SIP action, so there are SIP status codes that
...
... ISUP-specific and
have no corollary SIP action, so there are SIP status codes that
should not simply be translated to ISUP ...
... status codes that
should not simply be translated to ISUP - some SIP-specific action
should be attempted first. See the note on the (+) tag below.
...
... authenticate itself should cause code 21 be sent.
(+) If at all possible, a SIP gateway SHOULD respond to these
protocol errors ...
... re-originate the session. Only if this proves impossible should the
SIP gateway fail the ISUP half of the call.
...
...
When the Warning header is present in a SIP 606 or 488 message, there
may be specific ISDN cause code mappings appropriate to the Warning
...
... session. A CANCEL request MUST be
issued (a BYE is not used, since no final response has arrived from
the SIP side). A 200 OK for the CANCEL can be expected by the
gateway, and finally a 487 for the INVITE ...
... followed by an appropriate BYE request.
In SIP bridging situations, the REL message cannot be encapsulated in
...
... T11)] after receiving the latest address message." Since SIP
nodes have no obligation to respond to an INVITE ...
... nodes have no obligation to respond to an INVITE request within 20
seconds, SIP interworking inarguably qualifies as such a situation.
...
... encapsulated SUS rather than a re-INVITE. Note that the recipient of
such an INFO request may be a simple SIP phone that does not
understand ISUP (and would therefore take no action on receipt of
...
... INVITE could be sent to a
gateway from the SIP side in order to place the call on hold. This
re-INVITE will have an SDP offer ...
...
If, subsequent to the sending of the re-INVITE, the SIP side wishes
to take the remote end off hold and begin receiving media again, it
...
... gateway SHOULD stop sending media until the call is resumed and
SHOULD send a re-INVITE to the SIP leg of the call requesting that
the remote side stop sending media.
...
...
From the perspective of a gateway, either the SIP side or the ISUP
side can release a call, regardless of which side initiated the call.
...
... Note that cancellation of a call setup request (either from the ISUP
or SIP side) is discussed elsewhere in this document (in Section
8.2.7 and Section 7.2.3, respectively).
...
... SIP initiated release ...
...
When the caller hangs up, the SIP dialog MUST be terminated by
sending a BYE request (which is confirmed with a 200).
...
... network initiated). When the timer expires, the
REL is sent. This necessitates a slightly different SIP flow; see
Section 9 for more information on handling suspension. It is
...
... The gateways SHOULD behave as if a REL had been received in order to
release the dialog on the SIP side. A BYE or a CANCEL are sent
depending of the status of the call. See the procedures in Section
10.
...
... ACK Message (BLA) when the circuit is blocked - this
requires no corresponding SIP actions. Circuit Group Blocking (CGB)
...
... gateway, the gateway SHOULD NOT
send any corresponding SIP messages; the scope of the continuity
check applies only to the PSTN trunks, not to any IP ...
... gateway. CCR messages also do not designate any called
party number, or any other way to determine what SIP user agent
server should be reached.
...
... SIP proxy servers MAY route SIP messages on any signaling criteria
desired by network administrators ...
... headers are also
frequently of interest in making routing decisions. SIP-ISUP mapping
assumes that proxy servers ...
... assumes that proxy servers are interested in at least these three
fields of SIP messages, all of which contain URIs.
...
... URIs.
SIP-ISUP mapping frequently requires the representation of telephone
numbers in these URIs ...
... gateways will need to
translate the ISUP formats of these numbers into SIP URIs. In other
cases the reverse transformation will be required.
...
... cases the reverse transformation will be required.
The most common format used in SIP for the representation of
telephone numbers is the tel URL ...
... URL MAY constitute the entirety of a URI field in a
SIP message, or it MAY appear as the user portion of a SIP URI. For
example, a To field might appear as:
...
... URI field in a
SIP message, or it MAY appear as the user portion of a SIP URI. For
example, a To field might appear as:
...
... endpoint should formulate URIs
in the tel or SIP format is a matter of local administrative policy -
if the presence of a host portion would aid the surrounding network ...
... network
in routing calls, the SIP format should be used. A gateway MUST
accept either tel or SIP ...
... represented by the user portion of the URI, the SIP URI SHOULD
contain the optional ';user=phone' parameter; e.g.,
...
... However, it is strongly RECOMMENDED that only internationally
significant E.164 numbers be passed between SIP-T gateways,
especially when such gateways ...
... gateways are in different regions or different
administrative domains. In many if not most SIP-T networks, gateways
...
... are not responsible for end-to-end routing of SIP calls; practically
speaking, gateways have no way of knowing if the call will terminate
...
... gateways SHOULD always assume that calls require an international
numbering plan. There is no guarantee that recipients of SIP
signaling will be capable of understanding national dialing plans
...
... gateways SHOULD simply copy the provided digits
into the tel URL and append a 'user=phone' parameter if a SIP URI
format is used. Any non-standard or proprietary mechanisms used to
communicate further context ...
... identity has been omitted. This URI SHOULD be
a SIP URI with a display-name and username of 'Anonymous', e.g.:
...
...
For further information about privacy in SIP, see Section 5.7.
If presentation is set to 'address ...
... gateway does not support such
procedures, then the gateway SHOULD respond with appropriate SIP
status codes to express that the URI ...
... Query Response (CQR) are
used in many ISUP variants. These messages have no analog in SIP,
although receipt of a CQR may cause state reconciliation if the
...
... switches have become desynchronized; as
states are reconciled some calls may be terminated, which may cause
SIP or ISUP messages to be sent (as described in Section 10).
...
... signaling is always used. The ANSI
Exit Message (EXM) SHOULD NOT result in any SIP signaling in
gateways ...
... Although receipt of a Confusion (CFN) message is an indication of a
protocol error, corresponding SIP messages SHOULD NOT be sent on
receipt of a CFN - the CFN should be handled with ISUP-specific
...
... which the CFN responded). Only if ISUP procedures fails repeatedly
should this cause a SIP error condition (and call failure) to arise.
...
... INVITE
transaction is still not finished. Note that SIP does not ensure
that INFO requests are delivered in order, and therefore in adverse
network conditions ...
... be encapsulated in an INFO, provided that this will not be the first
SIP message sent in the backwards direction (in which case it SHOULD
be encapsulated in a provisional 1xx response). Similarly a message
...
... must have appeared in a previous provisional response or the message
might not be correctly routed to its destination. As such all SIP-T
gateways MUST send all provisional responses with a Contact header ...
... privacy and security concerns above and beyond those that have
been identified for other functions of SIP-T [9A]. Merely securing
encapsulated ...
... Number parameter is openly mapped to the From header. Section 12.2
shows how SIP Privacy [9B] should be used for this function. Since
...
... Privacy [9B] should be used for this function. Since
the scope of SIP-ISUP mapping has been restricted to only those
parameters that will be translated into the headers ...
... headers and fields used
to route SIP requests, gateways consequently reveal through
translation the minimum possible amount of information.
...
... ISUP bridging across SIP is discussed more fully in [9A], but Section
7.2.1.1 discusses processing the translated ISUP ...
... MGC that is authorized to use
ISUP over SIP in bridge mode. When requests are received from
arbitrary end points, gateways ...
...
In most respects, the information that is translated from ISUP to SIP
has no special security requirements. In order for translated
...
...
There are some concerns however that arise from the other direction
of mapping, the mapping of SIP headers to ISUP parameters, which are
...
... optional parameters in the Request-URI of a SIP, which can be created
directly by end users of a SIP device ...
... SIP, which can be created
directly by end users of a SIP device, map to those parameters at a
gateway. However, in the PSTN ...
... PSTN.
Since these fields are rendered as tel URL parameters in the SIP-ISUP
mapping, users can set the value of these fields arbitrarily.
...
... PSTN that support portability. It is not anticipated that end users
will typically set these SIP fields, and the risks associated with
allowing an adventurous or malicious user to set the LRN do not seem
to be grave, but they should be noted by network operators ...
... to be grave, but they should be noted by network operators. The
limited degree to which SIP signaling contributes to the interworking
...
... parameters incurs no foreseeable risks.
Some additional risks may result from the SIP response code to ISUP
Cause Code parameter mapping. SIP user agents ...
... SIP response code to ISUP
Cause Code parameter mapping. SIP user agents could conceivably
respond to an INVITE from a gateway ...
... respond to an INVITE from a gateway with any arbitrary SIP response
code, and thus they can dictate (within the boundaries of the
mappings supported by the gateway) the Q.850 cause code that will be
...
... off-line. However,
operators may want to scrutinize the set of cause codes that could be
mapped from SIP response codes (listed in 7.2.6.1) to make sure that
no undesirable network ...
... applications that rely on the Original Called Number for settlement
purposes could be affected by this mapping recommendation. It is
anticipated that future SIP work in this space will arrive at a
better general account of the re-targeting of SIP requests that may
...
... anticipated that future SIP work in this space will arrive at a
better general account of the re-targeting of SIP requests that may
be applicable to the OCN mapping.
...
...
The arbitrary population of the From header of requests by SIP user
agents has some well-understood security implications for devices
that rely on the From header ...
... caller). Note that gateways, like all other SIP user agents, MUST
support Digest authentication as described in [1 ...
... expressing Q.850 cause codes.
It is the contention of the authors that SIP introduces no risks with
regard to backwards media that do not exist in Q.931-ISUP ...
...
Unlike a traditional PSTN phone, a SIP user agent can launch multiple
simultaneous requests in order to reach a particular resource. It
would be trivial for a SIP user agent ...
... SIP user agent can launch multiple
simultaneous requests in order to reach a particular resource. It
would be trivial for a SIP user agent to launch 100 SIP requests at a
100 port ...
... simultaneous requests in order to reach a particular resource. It
would be trivial for a SIP user agent to launch 100 SIP requests at a
100 port gateway ...
... Transport Area IETF working groups that it called home (which
included the MMUSIC, SIP and SIPPING WGs). In particular, the
...
... Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261prop, June 2002. ...
... Vemuri, A., Peterson, J., "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", RFC 3372 ...
... Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323prop, November 2002. ...
... Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in SIP", RFC 3262prop, June 2002. ...