Subject: RE: [SIP] Early media

From: "Christian Huitema" <[email-masked]>
Date: Mon, 14 May 2001 09:21:50 -0700

There was quite a discussion of this subject at the IETF. One opinion is
that early media is in fact a form of session set-up, and that we should
not have 25 different ways to set-up a session. That means, there should
be no media at all until a 250/ACK exchange. Indeed, this could ease
firewall traversal a lot.

-- Christian Huitema

> -----Original Message-----
> From: Michel de Boer [mailto:[email-masked]]
> Sent: Monday, May 14, 2001 7:45 AM
> 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.

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