No subject

{quote}
13.2 UAC Processing

13.2.1 Creating the Initial INVITE

...
   There are special rules for message bodies that contain a session
   description - their corresponding Content-Disposition is "session".
   _SIP uses an offer/answer model_ where one UA _sends a session_
   _description, called the offer,_ which contains a proposed description
   of the session.  The offer indicates the desired communications means
   (audio, video, games), parameters of those means (such as codec
   types) and addresses for receiving media from the answerer.  The
   other _UA responds with another session description, called the_
   _answer,_ which indicates which communications means are accepted, the
   parameters that apply to those means, and addresses for receiving
   media from the offerer. An offer/answer exchange is within the
   context of a dialog, so that if a SIP INVITE results in multiple
   dialogs, each is a separate offer/answer exchange.  The offer/answer
   model defines restrictions on when offers and answers can be made
   (for example, you cannot make a new offer while one is in progress).
   This results in restrictions on where the offers and answers can
   appear in SIP messages.  In this specification, offers and answers
   can only appear in INVITE requests and responses, and ACK.  The usage
   of offers and answers is further restricted.
...
{quote}

(I added italics around some of the key points.)

Basic SIP depends on an Offer/Answer model.  Asterisk is making an offer and Lync is never answering.  How is Asterisk to establish a media connection if it doesn't know that the other endpoint has accepted the offer?

{quote}
21.1.5 183 Session Progress

   The 183 (Session Progress) response is used to convey information
   about the progress of the call that is not otherwise classified.  The
   Reason-Phrase, header fields, or message body MAY be used to convey
   more details about the call progress.
{quote}

This doesn't necessarily mean automatically that there is going to be Early Media.  183 means Session Progress not Early Media, although it can be used for that I guess and that is how I have commonly heard 183 referred to by.

Unless I am missing something.

I would be glad to hear from someone else though in regards to this.  My comment above was just pointing out why this was happening in Asterisk and that there seems to be a good reason why it is being handled this way.  It seems that if someone wants early media the most common way to do so is to have 183 with SDP (the answer).
                
      was (Author: elguero):
    Well, it is hard to answer.  I did a bunch of research before replying and I found comments indicating that Lync, for whatever reason, has decided to do something that most commercial implementations do not do; send 183 without SDP.  I even found a Microsoft forum post where someone was asking about this and the response was basically "is the application Lync certified?  Make sure to only use Lync certified apps."  I am paraphrasing that.

I could not find anything stating that 183 _has_ to contain SDP.  I think that is where the sticky point is.

There are some PBX servers out there that send 183 without SDP kind of like a "keepalive" while it is Trying.  That is why Asterisk currently ignores 183 without SDP due to one of those servers according to the comment in the code.  Everything I could find expects 183 to have SDP and I could not find anything stating how to handle 183 without SDP.  I even found where perhaps some PBXes send 183 with SDP after a 100 Trying and then afterwards send 183 without SDP.  If Lync was doing that, then we could handle that easily.

Here is how understand things based on what I have read and going back to the source, that being RFC 3261.