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 else 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).
                  
> Early media not properly handled on outbound TCP trunk
> ------------------------------------------------------
>
>                 Key: ASTERISK-21673
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21673
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/CallCompletionSupplementaryServices
>    Affects Versions: 11.3.0
>         Environment: FreePBX distro 3.211.63-7
> Centos 6.3, Asterisk 11.3.0 
>            Reporter: dcitelecom
>         Attachments: Early media Asterisk 11 log.txt
>
>
> Voxbone DID (defined in inbound routes) is sent out to customer trunk ABCco (TCP) trunk. They reply with 183 session progress (early media announcement) and Asterisk sends 180 ringing back to Voxbone.
> This is problematic where the DID is forwarded to a cell phone and the phone is off or the forwarding number was entered wrong. In both cases the user should hear an early media announcement that the user is not available or the number is not in service. Instead they hear a ring tone and don't know there is a problem. Log attached
> DIALPLAN
> exten => #0216479999999,1,Set(__FROM_DID=$
> {EXTEN}
> )
> exten => #0216479999999,n,Gosub(app-blacklist-check,s,1())
> exten => #0216479999999,n,Gosub(sub-record-cancel,s,1())
> exten => #0216479999999,n,Set(__REC_POLICY_MODE=never)
> exten => #0216479999999,n,Set(CDR(did)=$
> {FROM_DID}
> )
> exten => #0216479999999,n,ExecIf($[ "$
> {CALLERID(name)}
> " = "" ] ?Set(CALLERID(name)=$
> {CALLERID(num)}
> ))
> exten => #0216479999999,n,Set(CHANNEL(musicclass)=none)
> exten => #0216479999999,n,Set(__MOHCLASS=none)
> exten => #0216479999999,n,Set(__CALLINGPRES_SV=$
> {CALLERPRES()}
> )
> exten => #0216479999999,n,Set(CALLERPRES()=allowed_not_screened)
> exten => #0216479999999,n(dest-ext),Goto(ext-trunk,5,1)
> [ABCAsia] (trunk 5)
> disallow=all
> type=peer
> host=202.xxx.xxx.xxx
> transport=tcp
> allow=alaw
> allow=ulaw
> relaxdtmf=yes
> dtmfmode=rfc2833
> directmedia=yes
> context=from-ABCco-HK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira