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

[Olle E. Johansson]

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 [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.

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.

/O