Subject: [SIP] Early Media using the manyfolks draft

From: "Chris Hogg" <[email-masked]>
Date: Wed, 2 May 2001 13:39:22 +0100

Hi everyone,

I'd like to present the following for comment by the list:

Below is a proposal for handling some aspects of Early Media using both the
RFC2543bis-02 and the manyfolks draft for resource reservation. This
proposal could be applied in systems that will always use the manyfolks
extension to enable resource reservation, QoS, and security. An example
application would be the IMS in a 3GPP mobile network. In this example the
need for Early Media arises from interworking with the PSTN; specifically
for:
- delivery of call progress tones and
- to prevent clipping of voice on answer.

My question is: Is this interpretation of how the manyfolks draft can be
used in combination with the RFC2543bis-02 acceptable?

Early Media & Manyfolks:

- "Manyfolks" discusses how network QoS and security establishment can be
made a precondition to sessions initiated by SIP, and described by SDP.
- It allows SDP to be sent inside 1xx provisional responses (other than 100)
and PRACKs.
- Note that from a standards point of view the SDP is not to be used to
negotiate media and codecs. The sender of an SDP is required to accept any
of the media/codecs it included.
- However, if a system level requirement is imposed that a single media type
and codec is to be used in both send and receive directions, negotiation to
a single choice of media and codec is effectively what happens.

Call flow:

In this call flow the UAS is acting as the signalling gateway to the PSTN.
The details of what is included in the SDP body is omitted here for
simplicity, but it is assumed that the necessary parameters are included to
ensure that establishment of QoS is mandatory in both directions as a
precondition of the call. 

UAC                    UAS                 PSTN
---                    ---                 ----
                        |
1)INVITE[SDP]           |
------>                 |
             2)183[SDP] |
              <-------- |
3)PRACK [SDP]           |
------>                 |
              4)200 OK  |
              <-------- |
                        |
======> RESOURCE <===== |
    5) RESERVATION      |
                        |
            6)COMET[SDP]|
              <-------- |
7)200 OK(COMET)         |
------->                |
                        |
8)COMET[SDP]            |
------->                |
        9)200 OK(COMET) | 10)IAM
              <-------- | ------->
                        |
  11) 1-WAY MEDIA       | 12)BACKWARDS VOICE
<====================== |<====================
                        |
                        |               13)ACM
                        |             <--------
            14)183[SDP] |
              <-------- |
15)PRACK                |
------->                |
                        |                16)ANM
                        |             <--------
      18)200 OK(INVITE) |   17) 2-WAY VOICE
              <-------- |<====================>
                        |
  19) 2-WAY MEDIA       |
<======================>|
                        |
20)ACK                  |
------->                |

[Call now established. Rest of the call flow omitted]

SIP RFC2543bis02 draft offers a number of options for event #14. The UAS can
send any of the following to the UAC at this stage:

1. 180 with SDP, port=0 means called party alerting, play local ringing
2. 180 with SDP, port>0 means called party alerting, play media
3. 183 with SDP, port=0 means address complete, play local ringing
4. 183 with SDP, port>0 means address complete, play media
5. 180 without SDP means called party alerting, continue existing behaviour
6. 183 without SDP means address complete, continue existing behaviour
(In all cases the SDP can only include media agreed earlier by the UAC and
UAS.)

These options might be used for the following reasons in the example call
flow:
- 180 indicates that the ACM received included indication that the called
subscriber was free (and therefore alerting)
- 183 indicates that the ACM received did not indicate the status of the
callee
- Including SDP with port=0 indicates to the UAS to cease playing any media
and synthesise ringing
- Including SDP with port>0 indicates to the UAS to cease any local ringing
and play any arriving media
- Not including an SDP means the UAS should continue its current behaviour
regarding ringing or playing media

In the call flow above, the SDP in event #14 has a non-zero port number.
This has the effect of indicating to the UAC that it should continue to play
early media. Alternatively if we assume that in event #2 an SDP was included
in the 183 with port>0, the absence of SDP in #14 would have had the same
effect; i.e. that any early media arriving at the UAC would have continued
to be been played.

In this example call flow the caller at the UAC would have listened to early
media, carrying the sound of far end ringing from the PSTN between event #13
and #16/17.

Additional Issues arising:

1. The use of setting port numbers in SDP to 0 in order to indicate media
flow should cease is an IP specific solution and goes against the grain of
SIP being independent of the bearer protocol in use. This is a much wider
protocol issue.  Has any work been done on a generic method for indicating
media should stop being played?

2. In flow #14 above, the port number in the SDP may be set to 0 to indicate
to the UAC to stop playing any early media that it receives.  However, bis02
indicates that any SDP sent from a node refers to the media which that node
can receive.  Is it acceptable to use the backwards SDP (from UAS to UAC) to
indicate to the UAC to stop playing any early media that it is receiving or
is there a need for a new indication?

Any comments would be most welcome.

Many thanks

Chris Hogg
Strategic Product Planning
Nortel Networks 
Tel: +44 (0)1628-43-1720
email: [email-masked]

---

From: [email-masked]
Date: Wed, 2 May 2001 11:14:13 -0500

This is a good question. As we discovered at the interrim meeting in Plano,
there are a lot of extremely complicated issues surrounding it.

In the interest of keeping the majority of us who can still claim
sanity sane, I'd *strongly* suggest postponing discussion of this
issue on the list until we blow through a few more of our work
items (http://www.greycouncil.com/sipwg/draftstatus/lc_calendar.html).

/a

-----Original Message-----
From: Chris Hogg [mailto:[email-masked]]
Sent: Wednesday, May 02, 2001 7:39 AM
To: [email-masked]
Cc: Mark Watson
Subject: [SIP] Early Media using the manyfolks draft

Hi everyone,
I'd like to present the following for comment by the list:
Below is a proposal for handling some aspects of Early Media using both the
RFC2543bis-02 and the manyfolks draft for resource reservation. This proposal
could be applied in systems that will always use the manyfolks extension to
enable resource reservation, QoS, and security. An example application would be
the IMS in a 3GPP mobile network. In this example the need for Early Media
arises from interworking with the PSTN; specifically for:
- delivery of call progress tones and
- to prevent clipping of voice on answer.
My question is: Is this interpretation of how the manyfolks draft can be used
in combination with the RFC2543bis-02 acceptable?
Early Media & Manyfolks:
- "Manyfolks" discusses how network QoS and security establishment can be made
a precondition to sessions initiated by SIP, and described by SDP.
- It allows SDP to be sent inside 1xx provisional responses (other than 100)
and PRACKs.
- Note that from a standards point of view the SDP is not to be used to
negotiate media and codecs. The sender of an SDP is required to accept any of
the media/codecs it included.
- However, if a system level requirement is imposed that a single media type
and codec is to be used in both send and receive directions, negotiation to a
single choice of media and codec is effectively what happens.
Call flow:
In this call flow the UAS is acting as the signalling gateway to the PSTN. The
details of what is included in the SDP body is omitted here for simplicity, but
it is assumed that the necessary parameters are included to ensure that
establishment of QoS is mandatory in both directions as a precondition of the
call.

UAC                    UAS                 PSTN
---                    ---                 ----
                        |
1)INVITE[SDP]           |
------>                 |
             2)183[SDP] |
              <-------- |
3)PRACK [SDP]           |
------>                 |
              4)200 OK  |
              <-------- |
                        |

SIP RFC2543bis02 draft offers a number of options for event #14. The UAS can
send any of the following to the UAC at this stage:
1. 180 with SDP, port=0 means called party alerting, play local ringing
2. 180 with SDP, port>0 means called party alerting, play media
3. 183 with SDP, port=0 means address complete, play local ringing
4. 183 with SDP, port>0 means address complete, play media
5. 180 without SDP means called party alerting, continue existing behaviour
6. 183 without SDP means address complete, continue existing behaviour
(In all cases the SDP can only include media agreed earlier by the UAC and
UAS.)
These options might be used for the following reasons in the example call flow:
- 180 indicates that the ACM received included indication that the called
subscriber was free (and therefore alerting)
- 183 indicates that the ACM received did not indicate the status of the callee
- Including SDP with port=0 indicates to the UAS to cease playing any media and
synthesise ringing
- Including SDP with port>0 indicates to the UAS to cease any local ringing and
play any arriving media
- Not including an SDP means the UAS should continue its current behaviour
regarding ringing or playing media
In the call flow above, the SDP in event #14 has a non-zero port number. This
has the effect of indicating to the UAC that it should continue to play early
media. Alternatively if we assume that in event #2 an SDP was included in the
183 with port>0, the absence of SDP in #14 would have had the same effect; i.e.
that any early media arriving at the UAC would have continued to be been
played.
In this example call flow the caller at the UAC would have listened to early
media, carrying the sound of far end ringing from the PSTN between event #13
and #16/17.
Additional Issues arising:
1. The use of setting port numbers in SDP to 0 in order to indicate media flow
should cease is an IP specific solution and goes against the grain of SIP being
independent of the bearer protocol in use. This is a much wider protocol issue.
Has any work been done on a generic method for indicating media should stop
being played?
2. In flow #14 above, the port number in the SDP may be set to 0 to indicate to
the UAC to stop playing any early media that it receives.  However, bis02
indicates that any SDP sent from a node refers to the media which that node can
receive.  Is it acceptable to use the backwards SDP (from UAS to UAC) to
indicate to the UAC to stop playing any early media that it is receiving or is
there a need for a new indication?
Any comments would be most welcome.
Many thanks
Chris Hogg
Strategic Product Planning
Nortel Networks
Tel: +44 (0)1628-43-1720
email: [email-masked]

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.