Microsip online help

Establishing a call

Call establishing starts from creating an RTP audio session, because we need to advertise our RTP session IP:port in SDP. After that, we need to do NAT handling if it’s needed. Now the initial INVITE request can be created and send to the remote-party. For more details, RFC 3216 should be read (get the links below).

Example SIP messages exchanged

INVITE sip:bob@192.168.1.44 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.33;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@domain.com>
From: Alice <sip:alice@domain.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@192.168.1.33> 
Content-Type: application/sdp
Content-Length: sdp_size_in_bytes

v=0
o=- 2890844526 2890844526 IN IP4 192.168.1.33
s=
c=IN IP4 192.168.1.33
t=0 0
m=audio 1111 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=sendrecv

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.33;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3
To: Bob <sip:bob@domain.com>;tag=a6c85cf
From: Alice <sip:alice@domain.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.168.1.44>
CSeq: 314159 INVITE
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.33;branch=z9hG4bK4b43c2ff8.1;received=192.0.2.3
To: Bob <sip:bob@domain.com>;tag=a6c85cf
From: Alice <sip:alice@domain.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@1192.168.1.44>
Content-Type: application/sdp
Content-Length: sdp_size_in_bytes

v=0
o=- 2890844526 2890844526 IN IP4 192.168.1.44
s=
c=IN IP4 192.168.1.44
t=0 0
m=audio 2222 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=sendrecv

ACK sip:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.33;branch=z9hG4bKnashds9
Max-Forwards: 70
To: Bob <sip:bob@domain.com>;tag=a6c85cf
From: Alice <sip:alice@domain.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 ACK
Content-Length: 0

Call on-hold

Call on-hold in SIP is something that is not exactly defined. Actually, SIP doesn’t know anything about on-hold. On-hold is totally up to application to handle (this is because SIP doesn’t care about the SDP data it sends). Because of this, different implementations may handle it differently.

So far, I have seen four different ways how phones do it:

1. Setting the audio stream IP to «0.0.0.0» in SDP.
2. Disabling the audio stream in SDP by setting the port to «0».
3. Setting the audio stream to «sendonly» — normally call holder then sends an on-hold music to the remote-party.
4. A cleaner way is setting the audio stream to «inactive» (this is how we do it).

The main difference between disabling or setting an inactive audio stream is that in «inactive» RTCP, the session still exists and RTCP packets are sent. About RTP stream in «inactive», it is up to the application if it pauses session or disposes it in the on-hold state.

Example SDP (putting on-hold and un-hold)

v=0
o=- 2890844526 2890844526 IN IP4 192.168.1.33
s=
c=IN IP4 192.168.1.33
t=0 0
m=audio 1111 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=inactive


v=0
o=- 2890844526 2890844526 IN IP4 192.168.1.44
s=
c=IN IP4 192.168.1.44
t=0 0
m=audio 2222 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=inactive 

------------------------------------------------


v=0
o=- 2890844526 2890844526 IN IP4 192.168.1.33
s=
c=IN IP4 192.168.1.33
t=0 0
m=audio 1111 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=sendrecv


v=0
o=- 2890844526 2890844526 IN IP4 192.168.1.44
s=
c=IN IP4 192.168.1.44
t=0 0
m=audio 2222 RTP/AVP 0 97
a=rtpmap:0 PCMU
a=sendrecv

Normative References

SIP Signaling

• SIP, Session Initiation Protocol (RFC 3261) * SDP, Session
  Description Protocol (RFC 4566) * An Offer/Answer Model with Session
  Description Protocol (SDP) (RFC 3264) * Reliability of Provisional
  Responses in Session Initiation Protocol (RFC 3262) * HTTP
  Authentication: Basic and Digest Access Authentication (RFC 2617) *
  The Reason Header Field for the Session Initiation Protocol (RFC 3326)

Address Resolution

DNS resolution (RFC 3263) * Bonjour multicast DNS
(draft-lee-sip-dns-sd-uri-03)

NAT Traversal

SIP Signaling: Symmetric Response Routing Symmetric media (RFC
3581) * RTP media (Audio and Video): ICE, Interactive Connectivity
Establishment (RFC 5245) * MSRP media (Instant Messaging and File
Transfer): MSRP protocol relay extension (RFC 4976)

Audio and Video

RTP, A Transport Protocol for Real-Time Applications (RFC 3550) *
Real Time Control Protocol (RTCP) attribute in Session Description
Protocol (SDP) (RFC 3605) * SRTP, The Secure Real-time Transport
Protocol (RFC 3711) * Generation and parsing of telephone-events
payload in both RTP and SDP (RFC 2833) * ZRTP: Media Path Key
Agreement for Unicast Secure RTP (RFC 6189)

Instant Messaging

CPIM, Common Presence and Instant Messaging: (RFC 3862) * Session
Initiation Protocol (SIP) Extension for Instant Messaging (RFC
3428) * MSRP Protocol (RFC 4975) * Indication of Message Composition
for Instant Messaging (RFC 3994) * Message Summary Event Package (RFC
3842) * File Transfer (RFC 5547)

Screen Sharing

Variation of draft-garcia-mmusic-sdp-collaboration-00 using RFB
over MSRP

Conferencing

Conference Event Package (RFC 4575) * A Framework for Conferencing
with the Session Initiation Protocol (RFC 4353) * SIP Call Control —
Conferencing for User Agents (RFC 4579) * MSRP ad-hoc multi-party
chat sessions (RFC 7701)

Presence

SIP Specific Event Notification (RFC 3265) * SIP Extension for
Event State Publication (RFC 3903) * PIDF: Presence Data Model (RFC
3863, RFC 3379, RFC 4479) * Watcher-info Event Package (RFC 3857, RFC
3858) * Rich Presence Extensions to PIDF (RFC 4480) * Contact
Information Extension to PIDF (RFC 4482) * User Agent Capability
Extension to PIDF (RFC 5196) * XCAP Protocol (RFC 4825) * Common
Policy (RFC 4745) * Presence Rules (RFC 5025) * Resource Lists (RFC
4826) * RLS Services (RFC 4826) * PIDF manipulation (RFC 4827) *
XCAP Diff (RFC 5874) * OMA Reference Release Definition for XDM v1.1
and Presence SIMPLE v1.1 Implementation Guidelines * OMA XML
Document Management V1.1

Как правильно отмаркировать трафик?

Дано:

• Локальная сеть: 10.0.0.0/24
• Asterisk: 10.0.0.10
• WAN1: 1.1.1.1
• Address List: Asterisk (Сервер Asterisk 10.0.0.10 или список адресов IP телефонов)
• Address List: SIP-Trunk (Внешний SIP провайдер 9.9.9.9)

В Mangle добавляю правила:

Маркировка ИСХОДЯЩИХ соединений

• Chain: prerouting (Решение о маршрутизации еще не принятно. АТС находится за NAT и IP Asterisk (10.0.0.10) адрес меняется на внешний WAN 1.1.1.1) Провел эксперимент — можно ипользовать forward, что мне кажется более предпочтительно.
• Connection Mark: no-mark (Нам нужны только не маркированные соединения)
• Connection State: new (И только новые соединения)
• Src. Address List: Asterisk (В списке только один Asterisk сервер 10.0.0.10. Если у вас ВАТС, то в этот адрес лист добавляем IP телефонов)
• Dst. Address List: SIP-Trunk (Внешний SIP провайдер 9.9.9.9)
• New Connection Mark: SIP-Trunk (Соединение назовем SIP-Trunk)
• passthrough: Yes (Пропускаем обработку дальше)

Маркировка ВХОДЯЩИХ соединений

Нужно ли их маркировать?
Это же мы инициализируем подключение!
Провел тесты — входящие для Simple Queues МОЖНО НЕ МАРКИРОВАТЬ

• Chain: prerouting
• Connection Mark: no-mark (Нам нужны только не маркированные соединения)
• Connection State: new (И только новые соединения)
• Src. Address List: SIP-Trunk (Внешний SIP провайдер 9.9.9.9)
• Dst. Address List: Asterisk (В списке только один Asterisk сервер 10.0.0.10)
• New Connection Mark: SIP-Trunk (Соединение назовем SIP-Trunk)
• passthrough: Yes (Пропускаем обработку дальше)

Маркировка ПАКЕТОВ

• Chain: prerouting
• Packet Mark: no-mark
• Connection Mark: SIP-Trunk
• New Packet Mark: SIP-Trunk (Соединение назовем SIP-Trunk)
• passthrough: No (Запрещаем обработку дальше)

Заключение:
Если мы используем Simple Queues — имеет смысл маркировать только исходящие подключения. Входящие промаркируются тоже.
С точной маркировкой с IP адреса — на IP адрес, можно не указывать порты и протоколы. Либо указывайте TCP/UDP:5060+диапазон портов UDP (ГОЛОСА) и/или UDP:4569 для IAX2

В Qimple Queues создаем:

• Name: SIP-Trunk-WAN1
• Target: bridge (наша сеть, в которой Asterisk сервер или IP телефоны. Так же можно указать 0.0.0.0/0)
• Dst.: LAN1-WAN1 (Наш порт в Интернет)
• Max-Limit: 10M в Target Upload и Download (Максимум, сколько может потреблять SIP трафик. Значения должны быть одинаковыми, так как SIP трафик практически симметричен. Обычно на 1 внешнее подключение SIP требуется 64Кбит/сек. Но я выставляю с запасом 100Кбит/сек)
• Packet Marks: SIP-Trunk (Выбираем отмаркированные SIP пакеты)
• Limit At: 1M для Target Upload и Download (Минимально гарантированная пропускная способность. Расчитывается из кол-ва возможных соединений *100Кбит/сек)
• Queues Type: pcq-upload-default и pcq-download-default («Справедливая очередь»)
• Priority: 3 (1 высший приоритет — 8 нисший, при общих равных — выбирается у кого приоритет ниже хотя бы на единицу)

Если вам нужна помощь в настройке микротика — оставьте комментарий на странице

Background

SIP stands for ‘Sessions Initiation Protocol’, an IETF standard
described by RFC 3261. SIP is an application-layer control protocol
that can establish, modify and terminate multimedia sessions such as
Internet telephony calls (VoIP). Media can be added to (and removed
from) an existing session.

SIP allows the endpoints to negotiate and combine any type of session
they mutually understand like video, instant messaging (IM), file
transfer, desktop sharing and provides a generic event notification
system with real-time publications and subscriptions about state
changes that can be used for asynchronous services like presence,
message waiting indicator and busy line appearance.

SIP commands and terms used (in the example application)

• INVITE — Invite has two meanings:
  • Initial INVITE — In simple words, we or the remote-party just sends a call offer.
  • Mid-dialog INVITE — In SIP specifications, this is called «RE-INVITE».
• RE-INVITE is used to modify session info; in our case, implementing call onhold. RE-INVVITE can be sent by us or the remote-party.
• ACK — ACK must be sent to the remote-party for each INVITE/RE-INVITE positive 2xx response. ACK just confirms that we received a 2xx response.
• CANCEL — CANCEL can be used to cancel a pending INVITE or RE-INVVITE request.
• BYE — BYE is used to end the active call. The call terminating side must send the BYE.
• SIP dilaog — We can imagine this as a session between us and the remote-party.
• SIP call — An SIP call consists of an SIP dialog and an audio RTP session.

Introduction

This is a C# based simple SIP (VOIP) call-out phone. This SIP application was developed and is currently in use as «Help -> Call to support». The idea was to create a zero configuration, very simple call-out phone, and that is how it is now (though IP based incoming calls are supported; example: sip:test@ip:7666, 7666 is the port SIP_Call out runs).

Currently, this application runs on Windows only. For some reason .NET «still» has no managed support for audio-in and audio-out. The audio part uses the unmanaged Windows wave API.

I tried to make the example application well organized, clear, and well commented — don’t know how it turned out, you can be the judge. For beginners, I suggest you Google and read some SIP introduction, otherwise you will never get what is going on.

Because the code is full of comments, I think there is no need for a lot of explanation here; just dig into the code.

Features

The library has cross platform capabilities on Linux OS, Mac OSX and
Microsoft Windows. The library should work with minimal changes on
any platform that supports C and Python development environments.

The SDK is suitable for building end-points like SIP clients or SIP
Application Servers. To see what the SDK is capable of, you can try
Blink from http://icanblink.com

General

Written in Python * Non-blocking asynchronous engine * Built-in
configuration framework * TLS Security for signaling (SIP) and media
(MSRP, XCAP) * Support for multiple SIP accounts * Multiple Media
Types per Session (e.g. Video, Audio and IM) * Failover support for
DNS lookups, SIP and MSRP routing * Implements re-INVITEs for adding
and removing media streams * Automatically handling if IP Address
changes * Audio conference bridge * Wav player and recorder *
Acoustic Echo Cancelation * Answering machine * Wide-band Internet
audio codecs: Opus and Speex * PSTN compatible codecs: G722, G711,
iLBC, GSM * Video codecs: H.264, VP8

Supported media

Audio and Video (RTP/SRTP/ZRTP) * Instant Messaging (MSRP and its
relay extension) * File Transfer (MSRP and its relay extension) *
Screen Sharing (VNC over MSRP)

All media types can be combined together in the same SIP session.

Comments and Discussions

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

NAT handling

We support two different NAT handling methods:

1. STUN — A STUN request is sent to the STUN server, it replies back with — IP:port from where request came.
2. UPnP — The UPnP API is used to open router ports. This can be used only if router supports UPnP.

Calling is possible only if the router supports UPnP or if router type (STUN) is not «symmetric NAT«. For «symmetric NAT», each new UDP request to new IP:port is mapped to a new router, external new IP:port. For more info about NAT types, see: http://en.wikipedia.org/wiki/Network_address_translation.

There is a special case when the router supports SIP ALG (application layer gateway), then no NAT handling must be done by the application. The router alters SIP, SDP and opens router ports as needed. (So far I have seen Thompson routers do it.)