SIP 183 Session Progress Message

http://tools.ietf.org/html/draft-ietf-sip-183-00

 

 

SIP 183 Session Progress Message

Status of this Memo

This document is an Internet-Draft and is in full conformance with

all provisions of Section 10 of RFC2026
.

Internet-Drafts are working documents of the Internet Engineering

Task Force (IETF), its areas, and its working groups. Note that other

groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months

and may be updated, replaced, or obsoleted by other documents at any

time. It is inappropriate to use Internet- Drafts as reference mate-

rial or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
.

Abstract

This document describes a proposed extension to SIP [1
].  This exten-

sion adds the 183 Session Progress response and a new header to indi-

cate why a SDP message body is included in a 18x message.

The introduction of the 183 informational response message would

allow a called user agent to indicate to the calling user agent

whether or not the calling user agent should apply local alerting for

the session.  The existing 180 Ringing message would indicate that

the calling user agent has the option of providing local alerting

(and generally should).  The 183 Session Progress message would indi-

cate that the calling user agent should not provide local alerting.

In additionally, the calling user agent may be called on to establish

a media session to be used by the called user agent to indicate the

status of the session setup request as part of the indicated media

stream.  The indication of whether or not to play early media to the

calling user would be controlled with a new Session header included

in the 183 message.

Donovan, et al.         draft-ietf-sip-183-00.txt
Page 1

Internet Draft      SIP 183 Session Progress Message        October 1999

1
Introduction

There are instances, most notably dealing with SIP to PSTN interwork-

ing, that necessitate that the SIP called User Agent (UA) be able to

suppress local alerting by the SIP calling UA and to set up a prelim-

inary media session from the called UA to the calling UA. This would

allow the called UA to play back media prior to the full SIP session

being set up. This media would be used to report on the status of

the session setup request. It could also be used to play music while

the session setup is attempted. This would be useful for find-me

like services that involve attempting multiple locations for a single

setup request.

The only method in the current SIP specification that allows the

called UA to playback media is to set up a full SIP session. In PSTN

interworking situations (and likely in end-to-end SIP sessions) this

will cause a billing relationship to be established between networks

for the session. This causes a problem when the reason for setting

up the media session is to indicate a failure in the session setup.

This document proposes an extension to the Session Initiation Proto-

col (SIP) that introduces this capability.

Donovan, et al. draft-ietf-sip-183-00.txt
Page 2

Internet Draft SIP 183 Session Progress Message October 1999

2
PSTN Interworking Issues

In the PSTN today there are times when a media (voice) path is set up

from the called party to the calling party in order to play a treat-

ment (a special tone or announcement). The treatment can range from

alerting (ring back) to busy tones to announcements explaining why

the call could not be set up. The participants in this call are not

charged for the remote treatment portion of the call.

This one way voice path is generally set up as part of the processing

of the SS#7 ISUP ACM message.

The following call flow illustrates call setup using SS7 ISUP in a

PSTN network.

Originating Terminating

Network Network

IAM---------------------->

<----------------------ACM

<=========================

One way voice path

* <----------------------ANM

<========================>

Two way voice path

REL---------------------->

<----------------------RLC

* If the originating network is a Local Exchange Carrier and the termi-

nating network is an Interexchange Carrier then the LEC will start

charging for the call at this point in the call.

Donovan, et al. draft-ietf-sip-183-00.txt
Page 3

Internet Draft SIP 183 Session Progress Message October 1999

The following call flow illustrates the setup of a call that does not

result in a completed call but does involve a media path being set

up. In this case, the terminating network may be playing a busy sig-

nal or playing an announcement. The following are examples of

announcements that might be played in this scenario:

- The number you have dialed is no longer valid.

- The wireless subscriber you are calling is not currently reachable.

Originating Terminating

Network Network

IAM---------------------->

<----------------------ACM

<=========================

One way voice path

REL---------------------->

<----------------------RLC

2.1
PSTN to SIP Network Interworking Requirements

The following are a subset of the requirements for interworking

between a PSTN network and a SIP network.

When the SIP network is in the middle of two PSTN networks, it must

support the following:

- The ingress gateway into the SIP network shall have the ability to

determine, based on SIP signaling messages, when to send an ISUP ACM

message and when to send an ISUP ANM message.

- The SIP network shall have the ability to support fast setup. This

occurs when the terminating network does not send an ACM prior to

sending an ANM.

- The SIP network shall support the ability to cut through a voice

path from the terminating PSTN network to the originating PSTN net-

work without the interim SIP network incurring charges from the orig-

inating network.

The SIP network shall support the ability to place calls to a PSTN

network without the egress gateway knowing what type of device the

call was originated from. Thus, the egress gateway shall not need to

behave differently when the call originates from a PSTN network then

when the call originates from a native IP SIP device.

Donovan, et al. draft-ietf-sip-183-00.txt
Page 4

Internet Draft SIP 183 Session Progress Message October 1999

The following is an illustration of the two scenarios that must be

supported:

+-------------+ +---------+ +-------------+

| Originating | +-----+ | SIP | +-----+ | Terminating |

| PSTN |-->| IGW |-->| Network |-->| EGW |--->| PSTN |

| Network | +-----+ | | +-----+ | Network |

+-------------+ +---------+ +-------------+

IGW = Ingress Gateway

EGW = Egress Gateway

+---------+ +-------------+

| SIP | +-----+ | Terminating |

| IP |-->| EGW |--->| PSTN |

| Device | +-----+ | Network |

+---------+ +-------------+

2.2
Solution Options With Existing SIP Specification

The following sections show the results of investigating various

options for addressing the above requirements using existing SIP pro-

tocol capabilities. In each case, it is shown why the option either

cannot address the requirements or has short comings that can be bet-

ter addressed using the 183 Session Progress message.

2.2.1
100 Trying Mapped to ACM

The first option investigated involved mapping the 100 Trying message

to the ACM message.

The following call flow illustrates this option.

Originating Ingress Egress Terminating

Network SIP GW SIP GW Network

------------>------------>----------->

IAM INVITE IAM

<-----------<------------<------------

ACM 100 Trying ACM

<=========== <============

One way voice One way voice

The call flow breaks at this point for two reasons. First, at this

point in the call flow a one way voice path is needed so that the

terminating network can provide session setup status as part of the

voice path. The 100 Trying does not cause a voice path cut-through

between the ingress and egress gateways. This potentially could be

Donovan, et al. draft-ietf-sip-183-00.txt
Page 5

Internet Draft SIP 183 Session Progress Message October 1999

addressed by allowing the 100 Trying to carry SDP information to be

used for carrying the preliminary session media. This option is

explored in the context of the 180 Ringing message in section 3.3
.

The use of the 100 Trying also fails because a SIP Proxy Server sit-

ting in the signaling path between the ingress gateway and the egress

gateway might have generated the 100 Trying message. This would

result in the ACM message being sent prior to the egress gateway

receiving an ACM from the terminating network.

2.2.2
180 Ringing Mapped to ACM

The second option investigated was to use a 180 Ringing message to

trigger the ACM message at the ingress gateway.

This option is illustrated in the following call flow:

Originating Ingress Egress Terminating

Network SIP GW SIP GW Network

------------>------------>----------->

IAM INVITE IAM

<-----------<------------<------------

ACM 180 Ringing ACM

<=========== <============

One way voice One way voice

This option breaks at this point because a media voice path cannot be

cut through at this point for the terminating PSTN network to report

on the session progress. This is due to the fact that the egress

gateway has not yet communicated its RTP information to the ingress

gateway. The next two options attempt to address this issue.

Donovan, et al. draft-ietf-sip-183-00.txt
Page 6

Internet Draft SIP 183 Session Progress Message October 1999

2.2.3
180 With SDP Mapped to ACM

The next option investigated involves using the presence of SDP in

the 180 Ringing message to indicate that session progress will be

communicated by the called user agent using the media stream. In

this case, absence of the SDP message body would indicate that local

alerting should take place.

The following call flow illustrates this option:

Originating Ingress Egress Terminating

Network SIP GW SIP GW Network

------------>------------>----------->

IAM INVITE IAM

<-----------<------------<------------

ACM 180 Ringing ACM

One way SDP

<============

One way voice path

<-----------<------------<------------

ANM 200 OK ANM

Two way SDP

------------>

ACK

<====================================>

Two Way Voice Path

<-----------<------------<------------

REL BYE REL

----------->

RLC

------------>

200 OK

------------>

RLC

Although this option looks promising on first review, it does not

give the called user agent the ability to include SDP in the message

and rely on the calling user agent (the ingress gateway in this sce-

nario) to provide local alerting. As illustrated in [2
] there are

other reasons that SDP might be included in a 180 Ringing message.

Thus the user requiring a coupling of SIP and QOS signaling, which

requires inclusion of SDP in the 18x message, could not also request

local alerting.

Donovan, et al. draft-ietf-sip-183-00.txt
Page 7

Internet Draft SIP 183 Session Progress Message October 1999

2.2.4
200 OK Mapped to ACM

The final option investigated involves setting up a full media ses-

sion in the SIP network prior to receiving the ANM from the terminat-

ing PSTN network. This involves mapping the 200 OK to the ACM mes-

sage at the ingress gateway and having the egress gateway send a re-

INVITE upon receipt of the ANM. The ingress gateway would use the

re-INVITE to trigger the ANM message.

This option is illustrated in the following call flow:

Originating Ingress Egress Terminating

Network SIP GW SIP GW Network

------------>------------>----------->

IAM INVITE IAM

<-----------<------------<------------

ACM 200 OK ACM

One way SDP

------------>

ACK

<============

One way voice path

<-----------<------------<------------

ANM INVITE ANM

------------>

200 OK

<------------

ACK

<====================================>

Two Way Voice Path

<-----------<------------<------------

REL BYE REL

----------->

RLC

------------>

200 OK

------------>

RLC

Although this will work in the above scenario, it introduces additional

messaging overhead. In addition, as illustrated in the following fast

Donovan, et al. draft-ietf-sip-183-00.txt
Page 8

Internet Draft SIP 183 Session Progress Message October 1999

answer call flow, it is at best awkward and may result in clipping off

of the beginning of the voice call.

Originating Ingress Egress Terminating

Network SIP GW SIP GW Network

------------>------------>----------->

IAM INVITE IAM

<-----------<------------<------------

ACM 200 OK ANM

One way SDP

<-----------<------------

ANM INVITE

Two way SDP

------------>

ACK

<-----------

200 OK

----------->

ACK

<====================================>

Two Way Voice Path

<-----------<------------<------------

REL BYE REL

----------->

RLC

------------>

200 OK

------------>

RLC

Donovan, et al. draft-ietf-sip-183-00.txt
Page 9

Internet Draft SIP 183 Session Progress Message October 1999

2.3
Proposed 183 Session Progress

The following session signaling flows show the proposed solution

using the 183 Session Progress Message to map to the ISUP ACM message

and how the 183 Session Progress message is used for when the call

originates from a SIP IP Device.

2.3.1
PSTN to SIP to PSTN Session Using 183 Session Progress

The following session signaling flow shows the use of the 183 Session

Progress message for a session setup in a SIP based network when the

session will be between two PSTN networks.

Originating Ingress Egress Terminating

Network SIP GW SIP GW Network

------------>------------>----------->

IAM INVITE IAM

<-----------<------------<------------

ACM 183 Session ACM

Progress

One way SDP

<============

One way voice path

<-----------<------------<------------

ANM 200 OK ANM

Two way SDP

------------>

ACK

<====================================>

Two Way Voice Path

<-----------<------------<------------

REL BYE REL

----------->

RLC

------------>

200 OK

------------>

RLC

2.3.2
PSTN Fast Answer

The following session signaling flow shows the method for handling of

the fast answer scenario. Note that in this case the 183 Session

Progress message is not used, as the ANM is mapped directly to a 200

Donovan, et al. draft-ietf-sip-183-00.txt
Page 10

Internet Draft SIP 183 Session Progress Message October 1999

OK. This meets the requirement that the SIP gateways must be able to

differentiate between ACM and ANM messages.

Originating Ingress Egress Terminating

Network SIP GW SIP GW Network

------------>------------>----------->

IAM INVITE IAM

<-----------<------------<------------

ANM 200 OK ANM

Two way SDP

------------>

ACK

<====================================>

Two Way Voice Path

<-----------<------------<------------

REL BYE REL

----------->

RLC

------------>

200 OK

------------>

RLC

Donovan, et al. draft-ietf-sip-183-00.txt
Page 11

Internet Draft SIP 183 Session Progress Message October 1999

2.3.3
SIP to PSTN Session Using 183 Session Progress

The following session signaling flow shows the use of the 183 Session

Progress message for a session setup in a SIP based network when the

session originates in the SIP network and terminates to a PSTN net-

work.

Calling Egress Terminating

UA SIP GW Network

------------>------------>

INVITE IAM

<-----------

100 Trying

<-----------<------------

183 Session ACM

Progress

One way SDP

<========================

One way voice path

<-----------<------------

200 OK ANM

------------>

ACK

<========================

Two Way Voice Path

<-----------<------------

BYE REL

------------>

RLC

------------>

200 OK

3
Session Description Message Bodies in 18x Responses

The previous sections illustrated how the 183 response can be used to

communicate the need for the calling user agent to receive media

prior to receiving a final response from the called user agent.

There are other reasons for including SDP message bodies in an 18x

message.

One possible use is to use the SDP to establish security and/or QoS

relationship between the called and calling user agents, as

Donovan, et al. draft-ietf-sip-183-00.txt
Page 12

Internet Draft SIP 183 Session Progress Message October 1999

documented in [2
].

As a result, it is necessary to communicate to the calling user agent

why the SDP was included in the 18x message. The following section

describes the Session header, which will be used for this purpose.

3.1
Session Header in 18x Message Bodies

The Session header will be used to communicate to the calling user

agent the reason for a SDP message body being included in an 18x mes-

sage. The valid values for the Session header are Media, QoS and

Security. Multiple of these values can be indicated.

A value of Media indicates that the SDP should be used for establish-

ing of an early media session. The early media session will gener-

ally be used to communicate the status of the session but could also

be used for other reasons. For instance, it could be used to play

music while the calling user is being alerted.

A value of QoS indicates that the SDP should be used for establishing

of a QoS relationship between the calling and called user agents.

This could involve the user agents requesting QoS resources using

RSVP or some other signaling mechanism.

A value of Security indicates that the SDP should be used for estab-

lishing of a security relationship between the calling and called

user agents. This could be an IPSEC based relationship, for example.

4
Format and Usage

The format of provisional responses with media session descriptions

is identical to that of 200-class responses to INVITE requests,

except as noted in section 7
, "Reliability"; the body will contain a

session description (usually SDP; see ref [5
]).

4.1
. Temporary Media Establishment

Under most circumstances, provisional responses used to initiate tem-

porary media will contain SDP that is a subset of the media descrip-

tion presented in the INVITE message (as in normal 200 responses).

If the original INVITE message contains no media description, the

server will generate SDP representing the capabilities it requires

for media transmission and include it in the provisional response.

The client will include a final SDP in its acknowledgement of receipt

(see section 4
, "Reliability" ).

In both cases, the media streams will be established after the mes-

sage confirming receipt of the provisional response has been sent

(from the client's perspective) or received (from the server's per-

spective).

Donovan, et al. draft-ietf-sip-183-00.txt
Page 13

Internet Draft SIP 183 Session Progress Message October 1999

The designation of media capabilities in a provisional response has

no implications on the capabilities of any subsequent temporary con-

nections or the final connection. Each media stream is negotiated

relative to the session description in the original INVITE request

(or lack thereof).

4.2
. Change of Temporary Media

After a temporary media stream has been established, its parameters

can be changed by sending further provisional responses that also

contain session descriptions. Upon receipt of such a response, the

client MUST immediately cease transmission of media relating to the

old temporary stream. As before, the new temporary media stream is

established after acknowledgement of the provisional response.

Provisional responses which contain no session description SHOULD NOT

have an effect on any currently established temporary media stream.

4.3
. Discontinuation of Temporary Media

Sending of temporary media MUST be discontinued upon the sending

(from the server's perspective) or the receipt (from the client's

perspective) of any INVITE final response.

Sending a provisional response that contains a session description

with all media stream port numbers set to zero can also discontinue a

temporary media stream.

4.4
. New Provisional 183 Status Code

To allow for transmission of temporary media which does not corre-

spond to the four provisional status codes defined in the SIP RFC

(ref [1
]), this protocol extension defines one additional response

code of "183 Session Progress."

The 183 Session Progress response can be used for any arbitrary in-

band communication of call status. It SHOULD NOT, however, be used to

convey ringing, forwarding, or call queueing situations.

When applicable, the response text SHOULD include a text representa-

tion of the information conveyed by the media stream. In the case of

a recorded announcement, this text SHOULD be the text of the

announcement. For a tone, this text SHOULD be either the name of the

tone as defined in E.182 (ref [6
]) (e.g. "Payphone Recognition Tone")

or a description of the condition the tone is attempting to report

(e.g. "The Called Party is a Payphone").

4.5
Reliability

Clients which understand this extension SHOULD also understand the

extension described in "Reliability of Provisional Responses in SIP"

(ref [3
]) and indicate that they require reliable transmission of

Donovan, et al. draft-ietf-sip-183-00.txt
Page 14

Internet Draft SIP 183 Session Progress Message October 1999

provisional responses in Require: and Proxy-Require: headers.

4.6
Media Negotiation Failure for Temporary Media

If no acceptable media type is available in the client's INVITE

request session description, the server MAY return a "406 Not Accept-

able" message; the alternative is to forgo the transmission of provi-

sional media. While it is perhaps a more appropriate error code, "606

Not Acceptable" is not suggested, owing to its properties of termi-

nating any ongoing searches.

If the client finds the session description proposed by the server in

a provisional response unacceptable, its acknowledgement SHOULD con-

tain a session description with all media stream port numbers set to

zero. A server which receives such a message MAY respond with a "406

Not Acceptable" message; the alternative is to forgo the transmission

of provisional media.

4.7
Issues

There are situations when the called user agent (the UAS) requires

the support of the mechanisms defined in this document and does not

know through the INVITE message whether the calling user agent (the

UAC) supports the extension. There is currently no method for the

UAS to communicate to the UAC the required capabilities required to

properly setup the session.

This is a general problem with the SIP protocol that should be fixed

in an upcoming version. The mechanisms established for the SIP pro-

tocol will be used to indicate a need for this extension.

5
Proposed Extensions to the SIP Specification

The remainder of the document describes the proposed extensions to

the SIP specification. The section number indicates the section of

the SIP specification that requires modification. Thus section 5
.M.N

would include proposed modifications to section M.N of the SIP speci-

fication.

Absence of a section indicates that no modifications are proposed for

that section.

5.5.1.1
Status Codes and Reason Phrases

The following is the updated Figure 5:

Donovan, et al. draft-ietf-sip-183-00.txt
Page 15

Internet Draft SIP 183 Session Progress Message October 1999

Informational = "100" ; Trying

| "180" ; Ringing

| "181" ; Call is Being Forwarded

| "182" ; Queued

| "183" ; Session Progress

Success = "200" ; OK

Figure 5: Informational and Success codes

5.6
Header Field Definitions

The following needs to be added to Table 5

where enc. e-e ACK BYE CAN INV OPT REG

--------------------------------------------------------------

Session 18x e - - - - - -

5.6.43
Session

The session header is used in 18x response messages to communicate to

the UAC the purpose of the session description message body included

in response message.

The valid values are Media, QoS and Security.

A value of Media indicates that the SDP should be used for establish-

ing of an early media session. The early media session will gener-

ally be used to communicate the status of the session but could also

be used for other reasons. For instance, it could be used to play

music while the calling user is being alerted.

A value of QoS indicates that the SDP should be used for establishing

of a QoS relationship between the calling and called user agents.

This could involve the user agents requesting QoS resources using

RSVP or some other signaling mechanism.

A value of Security indicates that the SDP should be used for estab-

lishing of a security relationship between the calling and called

user agents. This could be an IPSEC based relationship, for example.

See [2
] for details on the handling of the QoS and Security values.

Session = "Session" ":" 1#( "Media" | "QoS" | "Security" )

5.7
Status Code Definitions

5.7.1
Informational 1xx

5.7.1.2
180 Ringing

Donovan, et al. draft-ietf-sip-183-00.txt
Page 16

Internet Draft SIP 183 Session Progress Message October 1999

The following text is proposed to be added to the description of the

180 Ringing message:

The calling UA should initiate local alerting (for instance, the

playing of a ringing tone or other alerting mechanism) so as to indi-

cate the progress of the session setup.

5.7.1.5
183 Session Progress

The called UA may have the need to communicate session progress with-

out the indication that the called user is being alerted.

The calling UA should not apply local alerting upon receipt of the

183 Session Progress Response.

The 183 Session Progress may have been sent to communicate the status

of the session setup attempt as part of a media stream. The called

user agent will indicate this by including the Session header with a

value of media.

In this case, the calling UA shall establish a media session accord-

ing to the contents of the session description contained in the 183

message. The calling UA should not apply local alerting that would

interfere with the media session information supplied by the called

UA.

The 183 message SHOULD include enough session description information

to allow for a media session between the called UA and the calling

UA.

Although not strictly required for a one way voice path to be setup

between the egress gateway and the ingress gateway, the SDP in the

183 has the following benefits:

1. The list of audio (or video) codecs is reduced, so the calling

gateway need only expect a smaller set.

2. The 183 can contain security preconditions in the SDP (if they

were in the SDP in the INVITE), so that the calling gateway can per-

form appropriate authentication/encryption for each media stream from

each egress gateway.

3. If any kind of pre-call announcement requires two-way media (per-

haps some kind of speech recognition for credit card numbers, or even

DTMF too), the SDP in the 183 is needed.

5.8
SIP Message Body

5.8.1
Body Inclusion

The following is proposed rewording of paragraph 2 in Section 8.1
of

the SIP specification:

Donovan, et al. draft-ietf-sip-183-00.txt
Page 17

Internet Draft SIP 183 Session Progress Message October 1999

For response messages, the request method and the response status

code determine the type and interpretation of any message body. All

responses MAY include a body. Message bodies for 1xx responses con-

tain advisory information about the progress of the request. In

addition, message bodies for 1xx responses can contain session

descriptions. 2xx responses ...

5.10
Behavior of SIP Clients and Servers

5.10.1.2
Responses

The following is proposed text for inclusion in section 10.1.2
of the

SIP specification:

183 responses SHALL always be forwarded.

5.11
Behavior of SIP User Agents

5.11.6
. Callee Needs Early Media

When the called UA receives and INVITE message that results in the

need to report on the status of the media setup through a media

stream, the called UA has the option to send a 183 message with a

session description to the calling UA.

5.11.7
Caller Receives 183 Response

When the calling UA receives a 183 response that contains a session

description and an indication that the session description is for

early media, it SHALL setup the associated media session and present

any media received from the called UA to the user.

5.13
Security Considerations

The security considerations for the 183 Session Progress message are

the same as for SIP in general.

Donovan, et al. draft-ietf-sip-183-00.txt
Page 18

Internet Draft SIP 183 Session Progress Message October 1999

5.16
Examples

5.16.9
PSTN to PSTN Session Setup (SIP in the middle)

The following call flow illustrates the case where a call is origi-

nating from a PSTN network, transiting a SIP network and being deliv-

ered to a second PSTN network. In this case, the 183 message is used

to trigger the ACM message and results in a one way media session

being setup through the SIP network.

Originating Ingress Egress Terminating

Network SIP GW SIP GW Network

------------>------------>----------->

IAM INVITE IAM

<------------

100 Trying

<-----------<------------<------------

ACM 183 Session ACM

Progress

SESSION: Media

One way SDP

<=====================================

One way voice path

<-----------<------------<------------

ANM 200 OK ANM

------------>

ACK

<====================================>

Two Way Voice Path

<-----------<------------<------------

REL BYE REL

----------->

RLC

------------>

200 OK

------------>

RLC

Donovan, et al. draft-ietf-sip-183-00.txt
Page 19

Internet Draft SIP 183 Session Progress Message October 1999

5.16.10
SIP User Agent Session Setup to a PSTN Destination

Calling Egress Terminating

UA SIP GW Network

------------>------------>

INVITE IAM

<-----------

100 Trying

<-----------<------------

183 Session ACM

Progress

Session: Media

One way SDP

<========================

One way voice path

<-----------<------------

200 OK ANM

------------>

ACK

<========================

Two Way Voice Path

<-----------<------------

BYE REL

------------>

RLC

------------>

200 OK

5.A Minimal Implementation

5.A.1 Client

The following is a suggested addition to Appendix A.1
of the SIP

specification:

PSTN Interworking: If a client wishes to interwork properly with PSTN

networks then it MUST support the 183 Session Progress message.

6
Further Examples

Only the relevant headers have been included in the following exam-

ples. Notably, the mandatory parameters Call-ID and CSeq are not

Donovan, et al. draft-ietf-sip-183-00.txt
Page 20

Internet Draft SIP 183 Session Progress Message October 1999

shown.

6.1
. Remote Ringtone, Followed by "Queued" Announcement

Client to server:

INVITE sip:+12145551212@bell.com SIP/2.0

RAck: 0

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

Require: org.ietf.sip.reliable-100

Proxy-Require: org.ietf.sip.reliable-100

Content-Type: application/sdp

v=0

o=- 929142225 929142225 IN IP4 vgw.domain.com

c=IN IP4 vgw.domain.com

M=audio 49152 RTP/AVP 0 1

a=rtpmap:0 PCMU/8000

a=rtpmap:1 1016/8000

Server to client:

SIP/2.0 180 Ringing

RSeq: 1

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

Session: Media

Content-Type: application/sdp

v=0

o=- 929142942 929142942 IN IP4 media.bell.com

c=IN IP4 media.bell.com

M=audio 49180 RTP/AVP 0

a=rtpmap:0 PCMU/8000

Client to server:

INVITE sip:+12145551212@bell.com SIP/2.0

RAck: 1

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

Require: org.ietf.sip.reliable-100

Proxy-Require: org.ietf.sip.reliable-100

[Remote ringing tone is played]

Donovan, et al. draft-ietf-sip-183-00.txt
Page 21

Internet Draft SIP 183 Session Progress Message October 1999

Server to client:

SIP/2.0 182 Call is queued; est. wait is 5 minutes

RSeq: 2

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

Session: Media

Content-Type: application/sdp

v=0

o=- 929143057 929143057 IN IP4 media.bell.com

c=IN IP4 media.bell.com

M=audio 49180 RTP/AVP 1

a=rtpmap:1 1016/8000

[Ring tone is discontinued]

Client to server:

INVITE sip:+12145551212@bell.com SIP/2.0

RAck: 2

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

Require: org.ietf.sip.reliable-100

Proxy-Require: org.ietf.sip.reliable-100

["Your call is queued" announcement is played, followed by hold

music]

Server to client:

SIP/2.0 200 OK

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

Content-Type: application/sdp

v=0

o=- 929143373 929143373 IN IP4 vgw.bell.com

c=IN IP4 mg.bell.com

M=audio 49199 RTP/AVP 1

a=rtpmap:1 1016/8000

[Hold music is discontinued]

Donovan, et al. draft-ietf-sip-183-00.txt
Page 22

Internet Draft SIP 183 Session Progress Message October 1999

Client to server:

ACK sip:+12145551212@bell.com SIP/2.0

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

[Final media stream is established]

6.2
. Remote Announcement: "Call is being forwarded," local ring tone.

Client to server:

INVITE sip:+12145551212@bell.com SIP/2.0

RAck: 0

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

Require: org.ietf.sip.reliable-100

Proxy-Require: org.ietf.sip.reliable-100

Content-Type: application/sdp

v=0

o=- 929142225 929142225 IN IP4 vgw.domain.com

c=IN IP4 vgw.domain.com

M=audio 49152 RTP/AVP 0 1

a=rtpmap:0 PCMU/8000

a=rtpmap:1 1016/8000

Server to client:

SIP/2.0 180 Call is being forwarded

RSeq: 1

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

Session: Media

Content-Type: application/sdp

v=0

o=- 929142942 929142942 IN IP4 media.bell.com

c=IN IP4 media.bell.com

M=audio 49180 RTP/AVP 0

a=rtpmap:0 PCMU/8000

Donovan, et al. draft-ietf-sip-183-00.txt
Page 23

Internet Draft SIP 183 Session Progress Message October 1999

Client to server:

INVITE sip:+12145551212@bell.com SIP/2.0

RAck: 1

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

Require: org.ietf.sip.reliable-100

Proxy-Require: org.ietf.sip.reliable-100

[Announcement plays: "Your call is being forwarded to a phone

outside the company's premises. Please wait."]

Server to client:

SIP/2.0 180 Ringing

RSeq: 2

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

Session: Media

Content-Type: application/sdp

v=0

o=- 929143373 929143373 IN IP4 media.bell.com

c=IN IP4 media.bell.com

M=audio 0 RTP/AVP 0

[Media stream is discontinued. Local ring-tone is generated by

the client towards the PSTN user.]

Client to server:

INVITE sip:+12145551212@bell.com SIP/2.0

RAck: 2

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

Require: org.ietf.sip.reliable-100

Proxy-Require: org.ietf.sip.reliable-100

Donovan, et al. draft-ietf-sip-183-00.txt
Page 24

Internet Draft SIP 183 Session Progress Message October 1999

Server to client:

SIP/2.0 200 OK

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

Content-Type: application/sdp

v=0

o=- 929143373 929143373 IN IP4 vgw.bell.com

c=IN IP4 mg.bell.com

M=audio 49199 RTP/AVP 1

a=rtpmap:1 1016/8000

Client to server:

ACK sip:+12145551212@bell.com SIP/2.0

To: sip:+12145551212@bell.com

From: sip:+15125559876@domain.com

[Final media stream is established]

7
References

[1
] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, SIP: Ses-

sion Initiation Protocol", RFC 2543
, March 1999.

[2
] J. Rosenberg, H. Schulzrinne, S. Donovan, "Establishing QoS and

Security Preconditions for SDP Sessions", draft-rosenberg-mmusic-

sipqos-00.txt
, To be published, Work in Progress.

[3
] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional Responses

in SIP", draft-ietf-mmusic-sip-100rel-01.txt
, May 21, 1999, Work in

Progress.

[4
] H. Schulzrinne, "RTP Profile for Audio and Video Conferences with

Minimal Control ", RFC 1890
, January, 1996.

[5
] M. Handley/V. Jacobson, "SDP: Session Description Protocol", RFC

2327
, April 1998.

[6
] "Application of Tones and Recorded Announcements in Telephone Ser-

vices", ITU-T Recommendation E.182; 1993.

Donovan, et al. draft-ietf-sip-183-00.txt
Page 25

Internet Draft SIP 183 Session Progress Message October 1999

8
Authors' Addresses

Steve Donovan

MCI Worldcom

1493/678

901 International Parkway

Richardson, Texas 75081

Email: steven.r.donovan@wcom.com

Matthew Cannon

BroadBandOffice Inc.

2070 Chain Bridge Road Suite G-99

Vienna VA, 22182

USA

Email: mcannon@broadbandoffice.net

Henning Schulzrinne

Dept. of Computer Science

Columbia University

1214 Amsterdam Avenue

New York, NY 10027

USA

Email: schulzrinne@cs.columbia.edu

Jonathan Rosenberg

Lucent Technologies, Bell Laboratories

Rm. 4C-526

101 Crawfords Corner Road

Holmdel, NJ 07733

USA

Email: jdrosen@bell-labs.com

Adam Roach

Ericsson Inc.

Mailstop L-04

851 International Pkwy.

Richardson, TX 75081

USA

Phone: +1 972-583-7594

Fax: +1 972-669-0154

E-Mail: adam.roach@ericsson.com