[general]
enable=yesunanswered = yes
https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Configuration_cdr
enable=yesunanswered = yes
This would cause the Multicast RTP Stream broadcast to begin on port 1234 of IP address 224.0.0.1 as soon as someone on your PBX in a Flash server dialed extension 1234 and began to speak. Every phone or SIP device listening for broadcasts on port 1234 from IP address 224.0.0.1 would receive the listen-only page on their speakerphone.exten => 1234,1,Dial(MulticastRTP/basic/224.0.0.1:1234)
SIP Session Establishment
This section details session establishment between two SIP User Agents (UAs): Alice and Bob. Alice (sip:alice@atlanta.example.com) and Bob (sip:bob@biloxi.example.com) are assumed to be SIP phones or SIP-enabled devices. The successful calls show the initial signaling, the exchange of media information in the form of SDP payloads, the establishment of the media session, then finally the termination of the call. HTTP Digest authentication is used by Proxy Servers to authenticate the caller Alice. It is assumed that Bob has registered with Proxy Server Proxy 2 as per Section 2 to be able to receive the calls via the Proxy.3.1. Successful Session Establishment
Alice Bob | | | INVITE F1 | |----------------------->| | 180 Ringing F2 | |<-----------------------|
| | | 200 OK F3 | |<-----------------------| | ACK F4 | |----------------------->| | Both Way RTP Media | |<======================>| | | | BYE F5 | |<-----------------------| | 200 OK F6 | |----------------------->|
| |
2.5. Unsuccessful Registration
Bob SIP Server | | | REGISTER F1 | |------------------------------>| | 401 Unauthorized F2 | |<------------------------------| | REGISTER F3 | |------------------------------>| | 401 Unauthorized F4 | |<------------------------------| | | Bob sends a SIP REGISTER request to the SIP Server. The SIP server provides a challenge to Bob. Bob enters her/his user ID and password. Bob's SIP client encrypts the user information according to the challenge issued by the SIP server and sends the response to the SIP server. The SIP server attempts to validate the user's credentials, but they are not valid (the user's password does not match the password established for the user's account). The server returns a response (401 Unauthorized) to Bob's SIP client. Message Details F1 REGISTER Bob -> SIP Server REGISTER sips:ss2.biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl To: Bob <sips:bob@biloxi.example.com> Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 1 REGISTER Contact: <sips:bob@client.biloxi.example.com> Content-Length: 0 Johnston, et al. Best Current Practice [Page 10]
RFC 3665 SIP Basic Call Flow Examples December 2003 F2 Unauthorized SIP Server -> Bob SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl To: Bob <sips:bob@biloxi.example.com>;tag=1410948204 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 1 REGISTER WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth", nonce="f1cec4341ae6ca9c8e88df84be55a359", opaque="", stale=FALSE, algorithm=MD5 Content-Length: 0 F3 REGISTER Bob -> SIP Server REGISTER sips:ss2.biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92 Max-Forwards: 70 From: Bob <sips:bob@biloxi.example.com>;tag=JueHGuidj28dfga To: Bob <sips:bob@biloxi.example.com> Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 2 REGISTER Contact: <sips:bob@client.biloxi.example.com> Authorization: Digest username="bob", realm="atlanta.example.com", nonce="f1cec4341ae6ca9c8e88df84be55a359", opaque="", uri="sips:ss2.biloxi.example.com", response="61f8470ceb87d7ebf508220214ed438b" Content-Length: 0 /* The response above encodes the incorrect password */ F4 401 Unauthorized SIP Server -> Bob SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92 ;received=192.0.2.201 From: Bob <sips:bob@biloxi.example.com>;tag=JueHGuidj28dfga To: Bob <sips:bob@biloxi.example.com>;tag=1410948204 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 2 REGISTER WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth", nonce="84f1c1ae6cbe5ua9c8e88dfa3ecm3459", opaque="", stale=FALSE, algorithm=MD5 Content-Length: 0
21.4.2 401 Unauthorized The request requires user authentication. This response is issued by UASs and registrars, while 407 (Proxy Authentication Required) is used by proxy servers.
When a UAS receives a request from a UAC, the UAS MAY authenticate the originator before the request is processed. If no credentials (in the Authorization header field) are provided in the request, the UAS can challenge the originator to provide credentials by rejecting the request with a 401 (Unauthorized) status code.
The question of best approach depends on what exactly your trying to
do. You only specified that you want to whisper music/message to a
single participent. Removing them from the conference for that will only
be MORE complicated. As far as how to, here is approximate code:
Dialplan:
Then originate a call (in this example were using a call file, although AMI would work just fine) as:
While my syntax may not be perfect here, this is the basic idea of how to stream/whisper data to a single participant. |
By Nick Galea, Google+ profile
Posted on : October 11, 2009, Last modified on : April 09, 2014 |