SIP Methods

From Yate Documentation
(Difference between revisions)
Jump to: navigation, search
(/* SIP Methods in Yate /* duplicated information ("not in ysipchan") moved to "generically ..."-section as an intro. Wording.)
 
(152 intermediate revisions by 3 users not shown)
Line 1: Line 1:
In this page we will find out more about what messages are handled by ysipchan module. In ysipchan.conf you can find a section called [methods] that allows Yate to process SIP methods by handling messages with name ''sip.methodname''.
+
Yate handles [[wikipedia:List of SIP request methods|SIP requests]] differently, depending on the request method.
<!--=== What are messages in Yate? ===
+
  
Messages are the main piece of Yate. They are used between modules insted of using functions. This is done mainly because if one module is changing to not have to change all the other modules that are dependent, and also because the debugging can be done in the engine much easier.
+
There are SIP requests methods that are handled internally in [[ysipchan]] module or generically in other Yate's [[modules]] or in [[External Module|external scripts]].
  
A message is a holder for several components:
+
You can also generate SIP requests from Yate (from other modules/custom scripts) and they will be sent to a specific party.
  
*    name - identifies the message type and allows matching it against the possible handlers
+
== What is a SIP Request Method? ==
*    return value - a string that is used as returned value by the emitter of the message
+
*    time - the time the message was created. This is important if the messages are queued for an indefinite amount of time
+
*    parameters - an arbitrary number (including zero) of string values, each having a name. Each handler can take action based on specific parameters and/or modify them. Unknown parameters must be ignored.
+
  
-->
+
A SIP request method defines the nature and the purpose of the SIP request.
<!--'''SIP requests''' are the codes used by Session Initiation Protocol for communication.  
+
  
 +
This the list of SIP request methods:
 +
* INVITE - Requests a session.
 +
* ACK - Final response to the INVITE
 +
* OPTIONS - Ask for server capabilities
 +
* BYE - Terminates a session
 +
* PRACK - Similar to ACK, but a provisional confirmation.
 +
* CANCEL - Cancel any pending requests.
 +
* REGISTER - Registers the client with the server according to the address in the To header field.
 +
* INFO - Sends information in the middle of a session that doesn't modify the session's state.
 +
* SUBSCRIBE -Subscribes the device for an event notification.
 +
* NOTIFY - Notifies all subscribers of an event.
 +
* PUBLISH - Publishes an event to a server.
 +
* REFER - Asks the client to issue a SIP request, typically a call transfer.
 +
* MESSAGE - Sends an instant message using SIP.
 +
* UPDATE - Modifies a session's state without altering the dialog state.
  
{|class="wikitable"
+
== SIP methods in Yate ==
|+ SIP requests
+
! Request name !! Description !! Defined in
+
|-
+
| INVITE || Indicates a client is being invited to participate in a call session. || RFC 3261
+
|-
+
| ACK || Confirms that the client has received a final response to an INVITE request. || RFC 3261
+
|-
+
| BYE || Terminates a call and can be sent by either the caller or the callee. || RFC 3261
+
|-
+
| CANCEL || Cancels any pending request. || RFC 3261
+
|-
+
| OPTIONS || Queries the capabilities of servers. || RFC 3261
+
|-
+
| REGISTER || Registers the address listed in the To header field with a SIP server. || RFC 3261
+
|-
+
| PRACK || Provisional acknowledgement. || RFC 3262
+
|-
+
| SUBSCRIBE || Subscribes for an Event of Notification from the Notifier. || RFC 3265
+
|-
+
| NOTIFY || Notify the subscriber of a new Event. || RFC 3265
+
|-
+
| PUBLISH || Publishes an event to the Server. || RFC 3903
+
|-
+
| INFO || Sends mid-session information that does not modify the session state. || RFC 6086
+
|-
+
| REFER || Asks recipient to issue SIP request (call transfer.) || RFC 3515
+
|-
+
| MESSAGE || Transports instant messages using SIP. || RFC 3428
+
|-
+
| UPDATE || Modifies the state of a session without changing the state of the dialog. || RFC 3311
+
|}
+
  
Some standard SIP methods can be handled generically in Yate:
+
In Yate some SIP requests are handled internally while others are handled generically.
  
- INVITE, CANCEL, ACK, BYE, REFER, OPTIONS and REGISTER are always handled internally<br>
+
When a SIP request arrives in Yate it will &ndash; depending on the request method &ndash; either be handled in the ysipchan module (internally handled), or an internal yate message named ''sip.methodname'' will be sent (generically handled). The handling of generically handled messages is done in other modules/external scripts.
- INFO in a dialog is handled internally, dialogless one is handled generically (using parameter lazy100 in [[SIP Configuration File|ysipchan.conf]])
+
-->
+
  
=== SIP Messages in Yate ===
+
=== Internally handled methods ===
  
Some standard SIP methods can be handled generically in Yate like INVITE, CANCEL, ACK, BYE, REFER, OPTIONS and REGISTER. SIP method INFO in a dialog is handled internally by Yate but dialogless is handled generically (using parameter lazy100 in [[SIP Configuration File|ysipchan.conf]]).
+
Internally handled request methods are requests handled directly by ysipchan module. Yate messages like ''sip.methodname'' won't be generated for them.
  
==== Messages emitted ====
+
The methods are handled internally by Yate:
<!--
+
* Channel related messages
+
** [[chan.startup]]
+
** [[chan.hangup]]
+
** [[chan.disconnected]]
+
** [[chan.dtmf]]
+
* Call related messages
+
** [[call.preroute]]
+
** [[call.route]]
+
** [[call.execute]]
+
** [[call.progress]]
+
** [[call.ringing]]
+
** [[call.answered]]
+
** [[call.update]]
+
* User related messages
+
** [[user.auth]]
+
** [[user.notify]]
+
** [[user.register]]
+
** [[user.unregister]]
+
* Specials
+
** [[chan.rtp]]-->
+
* [[Sip Generic|sip.<methodname>]] - where methodname is the name of the received SIP request
+
<!--** [[isup.decode]]-->
+
  
==== Messages handled ====
+
* methods that are always handled when ysipchan module is enabled
<!--* Channel related messages
+
** INVITE
** [[chan.masquerade]]
+
** CANCEL
** [[chan.locate]]
+
** ACK 
* Call related messages
+
** BYE
** [[call.route]]
+
* methods that are handled in the default configuration and that can be enabled/disabled from [general] section
** [[call.progress]]
+
** INFO - controlled by ''info'' setting. If request is received during a dialog initiated by an INVITE and it's used for application/dtmf-relay or application/dtmf then it's handled internally. Outside a dialog it's handled generically.
** [[call.ringing]]
+
** OPTIONS - controlled by ''options'' setting.
** [[call.answered]]
+
* methods that are handled in the default configuration when yate is started in server mode, and are disabled when yate is started in client mode. They can be enabled/disabled from [general] section
** [[call.update]]
+
** REFER - controlled by ''transfer'' setting
** [[call.drop]]
+
** REGISTER - controlled by ''register'' setting. If ''register=enabled'' then [registrar] section defines how Yate will work as a SIP REGISTRAR. Before starting yate as SIP registrar set users in regfile.conf or in register.conf.
* User related messages
+
* methods that are disabled in the default configuration but can be enabled/disabled from [general] section
** [[user.login]]
+
** PRACK - controlled by ''prack'' setting
* Module control and housekeeping
+
 
** [[engine.timer]]
+
=== Generically handled methods ===
** [[engine.halt]]
+
Generically handled SIP methods are methods that are not handled in the ysipchan module.
** [[engine.status]]
+
 
** [[engine.command]]
+
In order to handle other methods besides those listed above you must enable them in the [methods] section. Some have separate yate modules that handle them while others don't, so you need to define the handling of the message in a custom way when enabling them.
* Specials -->
+
 
* [[xsip.generate]] - is a message sent by a module (ysipchan module) requesting the transmission of a SIP request
+
When Yate receives a request for one of the enabled methods, it will generate a [[#SIP_generic_message|generic SIP message]]. This message will be handled from a module or from an external script.
 +
 
 +
=== Requests genenerated from Yate ===
 +
 
 +
In some cases you might need to initiate SIP requests from a module in Yate and send them to a specific party.
 +
 
 +
In this case you should send [[Xsip.generate|xsip.generate]] message from the module/script where the logic is implemented. The ysipchan module handles this message and sends the SIP request to the specified party.
 +
 
 +
This happens when Yate sends NOTIFY requests to the users that subscribed to a certain event. Or you can follow the setup for [[How_to_setup_chat_and_short_file_transfer_using_MESSAGE_Request_Method|sending chat messages between SIP users]] that uses both SIP generic messages and [[Xsip.generate|xsip.generate]].
 +
 
 +
== SIP generic message ==
 +
 
 +
SIP generic messages are messages generated by the [[SIP Configuration File|ysipchan]] module on receiving the specified requests in [methods] section.
 +
 
 +
=== Syntax ===
 +
 
 +
The syntax is: ''sip.methodname'', where methodname is the name of the received SIP request (e.g. sip.subscribe).
 +
 
 +
'''Parameters'''
 +
 
 +
;xsip_dlgtag
 +
:The dialog tag of the received request.
 +
;sip_uri
 +
:The request URI of the received SIP method.
 +
;xsip_type
 +
:The content type header.
 +
;sip_headername
 +
:Where headername is the name of the header received with the request. This parameter is repeated for each header in the request (e.g. sip_from, sip_to, etc).
 +
 
 +
'''Return'''
 +
 
 +
A module processing this message should set the 'code' parameter of the message to a SIP response code.
 +
 
 +
The processing module may also set message's parameters named osip_headername to be returned in the SIP response (e.g. osip_Expires).
 +
 
 +
=== Example ===
 +
 
 +
Yate receives a SIP request for MESSAGE method as below:
 +
 
 +
<sip:INFO> 'udp:0.0.0.0:5062' received 381 bytes SIP message from 192.168.168.156:5060 [0x890f858]
 +
------
 +
MESSAGE sip:234@192.168.168.156 SIP/2.0
 +
Via: SIP/2.0/UDP 192.168.168.156;rport;branch=z9hG4bKmibzipmn
 +
Max-Forwards: 70
 +
To: <sip:234@192.168.168.156>
 +
From: "DanielaGrigore" <sip:123@192.168.168.156>;tag=hhzbn
 +
Call-ID: xgjfitpjqqffbmz@localhost.localdomain
 +
CSeq: 427 MESSAGE
 +
Content-Type: text/plain;charset=utf-8
 +
User-Agent: Twinkle/1.4.1
 +
Content-Length: 12
 +
hello Monica
 +
------
 +
 
 +
And emits a '''sip.message''': 
 +
 
 +
Sniffed 'sip.message' time=1352472395.780609                                                                     
 +
  thread=0x890d348 'YSIP EndPoint'                                                                   
 +
  data=(nil)                                                         
 +
  retval='(null)'
 +
  param['username'] = '123'
 +
  param['realm'] = 'Yate'
 +
  param['ip_transport'] = 'UDP'
 +
  param['newcall'] = 'false'
 +
  param['domain'] = '192.168.168.156'
 +
  param['device'] = 'Twinkle/1.4.1'
 +
  param['connection_id'] = 'general'
 +
  param['connection_reliable'] = 'false'
 +
  param['username'] = '123'
 +
  param['called'] = '234'
 +
  param['caller'] = '123'
 +
  param['callername'] = 'DanielaGrigore'
 +
  param['antiloop'] = '19'
 +
  param['address'] = '192.168.168.156:5060'
 +
  param['ip_host'] = '192.168.168.156'
 +
  param['ip_port'] = '5060'
 +
  param['ip_transport'] = 'UDP'
 +
  param['sip_uri'] = 'sip:234@192.168.168.156'
 +
  param['sip_callid'] = 'xgjfitpjqqffbmz@localhost.localdomain'
 +
  param['xsip_dlgtag'] = '2078093122'
 +
  param['sip_to'] = '<sip:234@192.168.168.156>'
 +
  param['sip_from'] = '"DanielaGrigore" <sip:123@192.168.168.156>;tag=hhzbn'
 +
  param['sip_content-type'] = 'text/plain;charset=utf-8'
 +
  param['sip_user-agent'] = 'Twinkle/1.4.1'
 +
  param['xsip_type'] = 'text/plain'
 +
  param['xsip_body'] = 'hello Monica'
 +
 
 +
Follow the example below for a full configuration on how the enable and handle the MESSAGE method.
 +
 
 +
[[How to setup chat and short file transfer using MESSAGE Request Method]].
 +
 
 +
 
 +
'''See also'''
 +
 
 +
* [http://en.wikipedia.org/wiki/List_of_SIP_request_methods List of SIP request methods]
 +
* [[subscriptions|Subscriptions module]]
 +
* [[SIP Features Module]]
 +
* [[Telephony]]
 +
 
 +
[[Category:SIP]] [[Category:SIP Methods]] [[Category:SIP generic message]]

Latest revision as of 20:29, 13 March 2014

Yate handles SIP requests differently, depending on the request method.

There are SIP requests methods that are handled internally in ysipchan module or generically in other Yate's modules or in external scripts.

You can also generate SIP requests from Yate (from other modules/custom scripts) and they will be sent to a specific party.

Contents

[edit] What is a SIP Request Method?

A SIP request method defines the nature and the purpose of the SIP request.

This the list of SIP request methods:

  • INVITE - Requests a session.
  • ACK - Final response to the INVITE
  • OPTIONS - Ask for server capabilities
  • BYE - Terminates a session
  • PRACK - Similar to ACK, but a provisional confirmation.
  • CANCEL - Cancel any pending requests.
  • REGISTER - Registers the client with the server according to the address in the To header field.
  • INFO - Sends information in the middle of a session that doesn't modify the session's state.
  • SUBSCRIBE -Subscribes the device for an event notification.
  • NOTIFY - Notifies all subscribers of an event.
  • PUBLISH - Publishes an event to a server.
  • REFER - Asks the client to issue a SIP request, typically a call transfer.
  • MESSAGE - Sends an instant message using SIP.
  • UPDATE - Modifies a session's state without altering the dialog state.

[edit] SIP methods in Yate

In Yate some SIP requests are handled internally while others are handled generically.

When a SIP request arrives in Yate it will – depending on the request method – either be handled in the ysipchan module (internally handled), or an internal yate message named sip.methodname will be sent (generically handled). The handling of generically handled messages is done in other modules/external scripts.

[edit] Internally handled methods

Internally handled request methods are requests handled directly by ysipchan module. Yate messages like sip.methodname won't be generated for them.

The methods are handled internally by Yate:

  • methods that are always handled when ysipchan module is enabled
    • INVITE
    • CANCEL
    • ACK
    • BYE
  • methods that are handled in the default configuration and that can be enabled/disabled from [general] section
    • INFO - controlled by info setting. If request is received during a dialog initiated by an INVITE and it's used for application/dtmf-relay or application/dtmf then it's handled internally. Outside a dialog it's handled generically.
    • OPTIONS - controlled by options setting.
  • methods that are handled in the default configuration when yate is started in server mode, and are disabled when yate is started in client mode. They can be enabled/disabled from [general] section
    • REFER - controlled by transfer setting
    • REGISTER - controlled by register setting. If register=enabled then [registrar] section defines how Yate will work as a SIP REGISTRAR. Before starting yate as SIP registrar set users in regfile.conf or in register.conf.
  • methods that are disabled in the default configuration but can be enabled/disabled from [general] section
    • PRACK - controlled by prack setting

[edit] Generically handled methods

Generically handled SIP methods are methods that are not handled in the ysipchan module.

In order to handle other methods besides those listed above you must enable them in the [methods] section. Some have separate yate modules that handle them while others don't, so you need to define the handling of the message in a custom way when enabling them.

When Yate receives a request for one of the enabled methods, it will generate a generic SIP message. This message will be handled from a module or from an external script.

[edit] Requests genenerated from Yate

In some cases you might need to initiate SIP requests from a module in Yate and send them to a specific party.

In this case you should send xsip.generate message from the module/script where the logic is implemented. The ysipchan module handles this message and sends the SIP request to the specified party.

This happens when Yate sends NOTIFY requests to the users that subscribed to a certain event. Or you can follow the setup for sending chat messages between SIP users that uses both SIP generic messages and xsip.generate.

[edit] SIP generic message

SIP generic messages are messages generated by the ysipchan module on receiving the specified requests in [methods] section.

[edit] Syntax

The syntax is: sip.methodname, where methodname is the name of the received SIP request (e.g. sip.subscribe).

Parameters

xsip_dlgtag
The dialog tag of the received request.
sip_uri
The request URI of the received SIP method.
xsip_type
The content type header.
sip_headername
Where headername is the name of the header received with the request. This parameter is repeated for each header in the request (e.g. sip_from, sip_to, etc).

Return

A module processing this message should set the 'code' parameter of the message to a SIP response code.

The processing module may also set message's parameters named osip_headername to be returned in the SIP response (e.g. osip_Expires).

[edit] Example

Yate receives a SIP request for MESSAGE method as below:

<sip:INFO> 'udp:0.0.0.0:5062' received 381 bytes SIP message from 192.168.168.156:5060 [0x890f858]
------
MESSAGE sip:234@192.168.168.156 SIP/2.0
Via: SIP/2.0/UDP 192.168.168.156;rport;branch=z9hG4bKmibzipmn
Max-Forwards: 70
To: <sip:234@192.168.168.156>
From: "DanielaGrigore" <sip:123@192.168.168.156>;tag=hhzbn
Call-ID: xgjfitpjqqffbmz@localhost.localdomain
CSeq: 427 MESSAGE
Content-Type: text/plain;charset=utf-8
User-Agent: Twinkle/1.4.1
Content-Length: 12
hello Monica
------

And emits a sip.message:

Sniffed 'sip.message' time=1352472395.780609                                                                       
  thread=0x890d348 'YSIP EndPoint'                                                                     
  data=(nil)                                                           
  retval='(null)'
  param['username'] = '123'
  param['realm'] = 'Yate'
  param['ip_transport'] = 'UDP'
  param['newcall'] = 'false'
  param['domain'] = '192.168.168.156'
  param['device'] = 'Twinkle/1.4.1'
  param['connection_id'] = 'general'
  param['connection_reliable'] = 'false'
  param['username'] = '123'
  param['called'] = '234' 
  param['caller'] = '123'
  param['callername'] = 'DanielaGrigore' 
  param['antiloop'] = '19'
  param['address'] = '192.168.168.156:5060'
  param['ip_host'] = '192.168.168.156'
  param['ip_port'] = '5060' 
  param['ip_transport'] = 'UDP'
  param['sip_uri'] = 'sip:234@192.168.168.156'
  param['sip_callid'] = 'xgjfitpjqqffbmz@localhost.localdomain'
  param['xsip_dlgtag'] = '2078093122' 
  param['sip_to'] = '<sip:234@192.168.168.156>'
  param['sip_from'] = '"DanielaGrigore" <sip:123@192.168.168.156>;tag=hhzbn'
  param['sip_content-type'] = 'text/plain;charset=utf-8'
  param['sip_user-agent'] = 'Twinkle/1.4.1'
  param['xsip_type'] = 'text/plain' 
  param['xsip_body'] = 'hello Monica'

Follow the example below for a full configuration on how the enable and handle the MESSAGE method.

How to setup chat and short file transfer using MESSAGE Request Method.


See also

Personal tools
Namespaces

Variants
Actions
Preface
Configuration
Administrators
Developers