[asterisk-dev] Why do you want to send SIP requests in the multimedia RTP stream????
Olle E. Johansson
oej at edvina.net
Wed Jan 23 10:38:58 CST 2013
23 jan 2013 kl. 17:25 skrev Mark Michelson <mmichelson at digium.com>:
> 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 SUBSCRIBE dialog.
> "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.
That PJsip has a bad naming should not affect us... :-)
Use "call_dialog" for something connected to a channel and other types of dialogs for the rest, but please, please do not misuse "session" which makes it very hard to understand.
More information about the asterisk-dev