Subject: RE: [SIP] Early media

From: "Chris Hogg" <[email-masked]>
Date: Tue, 15 May 2001 11:42:10 +0100

Hi Michel,

While I can't help you with the status of the "early media" draft I can have
a go at answering a number of your other questions. I have been looking at
early media within SIP networks for some time now and recently sent an email
to the list (see attached email below).  The email describes a method for
achieving "early media" using bis02 and the "manyfolks" QoS draft.  It
discusses most of the issues you have raised including the issue of whether
or not 183 Session progress responses and 180 Ringing responses should or
should not contain SDP (and whether any meaning should be attached to this).

With respect to the issue of whether or not 2xx responses should contain SDP
even if the UAS does not want to modify the session it is my understanding
of 2543bis02 that SDP is always included in the 2xx response - I suppose
that if the UAS does not want to modify the session (as already agreed from
SDP in provisional responses) then it just re-sends the same SDP it sent in
its' last provisional response.  	Indeed there are actually a number
of situations whereby the UAS would wish to change the SDP in a 2xx response
even if all resources had already been negotiated and reserved as a result
of SDP within the INVITE and 1xx responses.  An example of this situation is
when the called party answers a call. The called party UAS sends a 200 final
response to the callers' UAC.  This 200 response must be able to alter the
media path between caller and callee from "recv only behaviour" (i.e. callee
UAS not listening - receiving port set to zero) to "send and recv behaviour"
(i.e. callee UAS is listening - receiving port no set to non-zero) (NOTE: At
all times the connection/media path is always "sendrecv" - it's just that
the callees' UAS can choose not to listen to incoming media hence implying
"recv only" behaviour).  Such behaviour is required in order to prevent the
caller from being able to talk to the callee during call set up (during
which time the call is not billed).

Any comments on the proposed "early media" call flow would be welcome.

Cheers
Chris 

Chris Hogg
Strategic Product Planning
Nortel Networks (UK)
Tel: +44 (0)1628-431720

From:	Hogg, Chris [MAIFP:EP21:EXCH]
Sent:	04 May 2001 09:49
To:	[email-masked]'
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  | 
              <-------- | 
                        | 
======> 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] 

-----Original Message-----
From: Michel de Boer [mailto:[email-masked]]
Sent: 14 May 2001 15:45
To: [email-masked]
Subject: [SIP] Early media

Hi,

Can someone tell me what the current status of early media handling
in SIP is. draft-ietf-sip-183-00.txt has been expired for a while.
Digging through the mailing list, the last reference I found was that
the work from this draft was disbandoned and that a new early media
approach would be worked out (see mail I added to this).

The 2543bis is not very clear with respect to early media.
Section 7.1 says that if a 1xx response contains a session
description, a UAC SHOULD cease generating local ringback
tone. It does not say what it should do instead. Does SDP
in a 1xx mean that there is early media?

Section 8.1 says that 1xx responses MAY contain session
description and that the interpretation of the body depends
on the status code. Where can I find this interpretation?

It says that generally it informs the caller what kind of
session the callee is likely to establish, subject to later
modification in the 2xx response. If a UAS doesn't want to
modify it, can it send a 2xx without SDP? In my opinion
that should be fine, but 2543bis says 2xx responses to INVITE
requests contain session descriptions.

Regards,
Michel

Alan Johnston wrote:
> 
> Robert,
> 
> See my comments below.
> 
> Thanks,
> Alan Johnston
> sip:[email-masked]
> 
> "Fairlie-Cuninghame, Robert" wrote:
> 
> >
> >
> > Hi,
> >
> > I recently noticed in the call flow documents that it states that early
media sessions can be established by simply
> > returning a 183 without SDP (giving the argument that the early media is
unidirectional and thus only needs the
> > caller's SDP).
> >
> > I don't remember this change being discussed on the list and I have not
seen this behavior stated in any of the bis
> > or old-183 drafts. Where did it come from  and why?
> >
> 
> It was discussed at the interim meeting in Plano and also at Minneapolis.
I did not agree with the conclusion, but I
> have updated the call flows draft to reflect the consensus.  The consensus
was that early media is problematic, and as
> a result the 183 Session Progress approach described in the expired 183
draft
> (http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-183-00.txt) will be
abandoned in favor of a yet to be designed
> early media approach that is friendly to forking, hold, etc.  As a result,
2543bis will list the 183 code, but without
> any requirements.  Also, putting SDP in a 183 also becomes undefined by
any SIP WG document.
> 
> >
> > Although strictly speaking, the SDP is not required I still think it
should still be required in the 183 response
> > because:
> >
> >   a. it  now forms a response-code specific behavior that is in contrast
to the general early media handling for
> >      other provisional responses, eg SDP in 180.
> >   b. Does not allow symmetric RTP or any other type of NAT friendly
processing to occur (because the source address
> >      is unknown).
> >   c. Is an unnecessary "saving". Why not send the SDP? Sending the
reverse SDP doesn't hurt and is in line with
> >      processing for other early media sessions (eg 180 with SDP). Just
because the both SDP are specified, does not
> >      mean that the UAS need accept any media in the forward direction.
> >
> >
> I agree that the 183 with SDP is useful, however, others were insistent
that it not be standardized.
> 
> >
> >
> > What do other people think? I know we all hate early media but at least
let's make the handling of what we have
> > consistent across all response codes.
> >
> > Cheers,
> >
> > Robert.

_______________________________________________
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.