[asterisk-dev] Why do you want to send SIP requests in the multimedia RTP stream????

[Mark Michelson]

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 [1]) (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
>           field.
>
> 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.

Mark Michelson