[asterisk-dev] Why do you want to send SIP requests in the multimedia RTP stream????
mmichelson at digium.com
Wed Jan 23 10:25:27 CST 2013
On 01/23/2013 02:27 AM, Olle E. Johansson wrote:
> 22 jan 2013 kl. 20:58 skrev SVN commits to the Digium repositories <svn-commits at lists.digium.com>:
>> Create common method for sending SIP requests in a session.
> Why are you sending SIP requests in the multimedia path????
> SIP is used to manage sessions - but the SIP status of a "call" is named "dialog".
> RFC 3261:
> Session: From the SDP specification: "A multimedia session is a
> set of multimedia senders and receivers and the data streams
> flowing from senders to receivers. A multimedia conference is
> an example of a multimedia session." (RFC 2327 ) (A session
> as defined for SDP can comprise one or more RTP sessions.) As
> defined, a callee can be invited several times, by different
> calls, to the same session. If SDP is used, a session is
> defined by the concatenation of the SDP user name, session id,
> network type, address type, and address elements in the origin
> Dialog: A dialog is a peer-to-peer SIP relationship between two
> UAs that persists for some time. A dialog is established by
> SIP messages, such as a 2xx response to an INVITE request. A
> dialog is identified by a call identifier, local tag, and a
> remote tag. A dialog was formerly known as a call leg in RFC 2543.
> Using something closer to either RFC terminology or asterisk terminology - "channels"
> makes it easier for new (and old grumpy) developers to understand your code and
> refer back to the standards.
> And it will make it easier for you as you discuss SIP stuff with other developers at SIPit 30 in North Carolina.
> /O ;-)
Thanks for the suggestion. The problem in this particular case is
"dialog", "session", and "channel" don't fit well here.
"Dialog" doesn't work because this function (and all functions in
res_sip_session) is not intended to be used for any dialog. This only
works for dialogs that set up media sessions (i.e. INVITE-initiated
dialogs). When a SUBSCRIBE/NOTIFY API is added, there will be a separate
function in a separate header used for sending a request on the
"Session" doesn't work, as you have mentioned, because it refers to the
media session, not the SIP dialog.
"Channel" doesn't work because channel is a completely separate concept
from the SIP signalling. While the situation is rare and unlikely, the
new API provides the ability to have a SIP INVITE dialog without any
ast_channel ever being used. We're trying our best not to intermix
Asterisk channels in the general SIP API.
The compromise here so far is to use the term "SIP session" to refer to
a dialog that was initiated by an INVITE. This also jibes with the PJSIP
concept of the pjsip_inv_session structure, which describes the same
concept. I'll add a note into res_sip_session.h that explains this and
I'll be more careful with commit messages and comments, so that they are
more clear to someone familiar with SIP.
More information about the asterisk-dev