Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping

Voir toute la rfc dans une seule page

Télécharger le PDF

RFC 3398                  ISUP to SIP Mapping              December 2002


5.3 Transmission of Dual-Tone Multifrequency (DTMF) Information

   How DTMF tones played by the user are transmitted by a gateway is
   completely orthogonal to how SIP and ISUP are interworked; however,
   as DTMF carriage is a component of a complete gatewaying solution
   some guidance is offered here.

   Since the codec selected for voice transmission may not be ideally
   suited for carrying DTMF information, a symbolic method of
   transmitting this information in-band is desirable (since out-of-band
   transmission alone would provide many challenges for synchronization
   of the media stream for tone re-insertion).  This transmission MAY be
   performed as described in RFC2833 [5].

5.4 Reliable Transmission of Provisional Responses

   Provisional responses (in the 1xx class) are used in the transmission
   of call progress information.  PSTN interworking in particular relies
   on these messages for control of the media channel and timing of call
   events.

   When interworking with the PSTN, SIP messages MUST be sent reliably
   end-to-end; reliability of requests is guaranteed by the base
   protocol.  One application-layer provisional reliability mechanism
   for responses is described in [18].

5.5 Early Media

   Early media denotes the capability to play media (audio for
   telephony) before a SIP session has been established (before a 2xx
   response code has been sent).  For telephony, establishment of media
   in the backwards direction is desirable so that tones and
   announcements can be played, especially when interworking with a
   network that cannot signal call status out of band (such as a legacy
   MF network).  In cases where interworking has not been encountered,
   use of early media is almost always undesirable since it consumes
   inter-machine trunk recourses to play media for which no revenue is
   collected.  Note that since an INVITE almost always contains the SDP
   required to send media in the backwards direction, and requires that
   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 systems.  However,
   this mechanism has a number of limitations - for example, media
   streams offered in the SDP of the INVITE cannot be modified or
   declined, and bidirectional RTCP required for session maintenance
   cannot be established.





Camarillo, et. al.          Standards Track                     [Page 8]