Sip Concept

standards

sip-standards.png

RFC summary

http://www.cs.columbia.edu/sip/drafts.html

Hitchhiker's Guide to SIP

http://tools.ietf.org/html/rfc5411

classified by IETF working group.
http://www.voip-telephony.org/rfc/iptel

working groups

https://docs.google.com/a/google.com/viewer?url=http://www.arca-technologies.com/white_papers/ibm_sip.pdf

The following working groups at the IETF work on SIP directly and indirectly:

  • SIP – The original SIP group. Now deals with extensions to the standard.
  • SIPPING – Session Initiation ProPosal INvestiGation. This group is responsible for examining new requirements for the SIP protocol and deciding if an extension to the protocol is required.
  • SIMPLE – SIP for Instant Messaging and Presence Leveraging Extensions. This group is responsible for the IM and presence extensions for SIP.
  • XCON – Centralized CONferencing. This group is responsible for creating a set of protocols for tightly coupled multimedia conferences. Not all the protocols of this group will be SIP, but some (if not most) of them will be.

jungle of multi party RFC

http://blog.tekelec.com/blog/bid/13345/Multiparty-Communications-in-SIP-A-Brief-History

sip-i vs sip-t

http://blog.tekelec.com/blog/bid/8995/FAQ-What-are-SIP-I-and-SIP-T

overview of sip

SIP FAQ: https://egyed.com/faq/sip_faq.html
Diagrams : http://www.tech-invite.com/Ti-sip-service-4.html http://www.in2eps.com/fo-sip/tk-fo-sip-dialog.html
Book:
SIP: understanding the Session Initiation Protocol By Alan B. Johnston

http://www.dialogic.com/webhelp/IMG1010/10.5.2/WebHelp/Description/SIP/intro_sip.htm

sip refresher

http://www.vocal.com/sip/session_timers.html
http://webcache.googleusercontent.com/search?q=cache:9n2G7hfNEIAJ:jaymzworld.com/wiki/Session_Manager_Troubles+&cd=1&hl=en&ct=clnk&gl=us

http://www.dialogic.com/webhelp/img1010/10.5.3/webhelp/Description/SIP/SIP_Session_Timer_Call_Flows.htm

service concept

SIP trunk

http://www.ciscosystems.net.mu/en/US/prod/collateral/voicesw/ps6790/gatecont/ps5640/prod_white_paper0900aecd806780df.html

sip core cencepts

strict routing vs loose routing.

http://www.softarmor.com/sipwg/references/SIPIT10_NEWRFC.ppt

dtmf

http://myprojectguide.org/c/ais/sip.html

In a SIP based IP telephony calls, DTMF signals may be carried as (1) embedded audio, in which case the low bandwidth codecs distort the signal, causing problems in recognization at the receiving end, (2) special RTP packet as per RFC 2833 and signalled as telephone-event media type, or (3) SIP INFO request containing message body describing the signal. The option (2) is preferred, since it avoids the signaling path.

headers:

sip headers are cases -insensitive (sip requests are case sensitive)

  • allow : supported methods
  • supported: indicated supported feature capabilities by UAC/UAS. normally it is in response to OPTIONS request.
  • allow-events: indicates the events packages it supports
  • accept : media types.

SDP

fmtp: format parameters of transport.

DNS

http://mit.edu/sip/sip.edu/dns.shtml
http://blog.tekelec.com/blog/bid/13206/How-do-SIP-endpoints-find-the-right-servers
http://sipdroid.wordpress.com/category/srv/

DNS provides two record types relevant to SIP requests: SRV and NAPTR. Some implementations will use SRV records only.

- NAPTR records provide a mechanism for the called domain to specify which protocols it prefers a SIP request to use.
SIP+D2U for SIP over UDP
SIP+D2T for SIP over TCP
SIP+D2S for SIP over SCTP

SIPS+D2T for secure SIP over TLS over TCP. (TLS over UDP is not defined. )

- SRV records: for determining the SIP host address, port of the host to which a SIP request is sent.

stateful vs stateless

early media

http://blog.tekelec.com/blog/?Tag=Early+Media
early media

NAT

secure

- no secure
- authenticated: only message authentication is enabled for SIP in TLS, no encryption of SIP.
- encrypted: SIP in TLS has both message authentication and encryption. RTP is both authenticated(header fields + payload) and encrypted(payload only) : sRTP

- default authentication: HMAC-SHA1
- default cipher for encryption is AES in 128 bits encryption key.

symmetric keying is normally used for encryption algorithms, such as AES, as well as authentication transforms, such as HMAC-SHA1. the actual process for exchanging
of keying material for sRTP has two approaches:

  • in SDP of signal flow. RFC 4568
  • datagram TLS (dTLS) in media flow RFC 4347

http://www.ccierants.com/2010/08/sip-call-flow-troubleshooting.html

headers

http://www.networksorcery.com/enp/protocol/sip.htm

http://manoftoday.wordpress.com/?s=sip

CSeq

A UA must maintain the state on calls that it initiates or participates in. A minimum call state set includes the local and remote tags, Call-ID, local and
remote CSeqheader fi elds, along with the route set and any state information necessary for the media. This information is used to store the dialog information
and for reliability. Even after a call has been terminated, the call state must be maintained by a user agent for at least 32 seconds in case of lost
messages in the call tear down.

The remote CSeq storage is necessary to distinguish between a new request and a retransmission of an old request.

  • A re-INVITE is used to change the session parameters of an existing or pending call. It uses the same Call-ID and tagsas the original INVITE/200 OKexchange, but the CSeq is incremented because it is a new request.
  • A retransmitted INVITE will contain the same Call-ID and CSeq as a previous INVITE.

The CSeq number is never
incremented for an ACK, but the CSeq method is changed to ACK. This is so that a UAS can match the CSeqnumber of the ACKwith the number of the correspond-ing INVITE.

CANCEL

CANCEL is a hop-by-hop request and receives a response generated by the next stateful element.

The CSeq is not incremented for this method so that proxies and user agents can match the CSeq of the CANCEL with the CSeq of the pending INVITE to
which it corresponds.

The branchID for a CANCEL matches the INVITE that it is canceling. A CANCEL only has meaning for an INVITE since only an INVITE may take several
seconds (or minutes) to complete. All other SIP requests complete immediately (that is, a UAS must immediately generate a fi nal response). Consequently, the
fi nal result will always be generated before the CANCEL is received.

branch id

http://tools.ietf.org/html/rfc3261

The branch parameter is a transaction identifi er. Responses relating to this request can be correlated because they will contain this same transaction identifier.

A response matches a client transaction under two
conditions:

1. If the response has the same value of the branch parameter in
the top Via header field as the branch parameter in the top
Via header field of the request that created the transaction.

2. If the method parameter in the CSeq header field matches the
method of the request that created the transaction. The
method is needed since a CANCEL request constitutes a
different transaction, but shares the same value of the branch
parameter.

Reliability

Reliability mechanisms in SIP include:
- Retransmission timers;
- Increasing command sequence CSeq numbers;
- Positive acknowledgments.

OPTIONS ping

http://www.packetizer.com/in/q122.html
http://social.technet.microsoft.com/Forums/en-US/ocsvoice/thread/01e64876-af93-479a-bb32-75ac59fba8b5

rport

strict vs loose routing

SIP Security TLS & sRTP

SBC

http://www.likewise.am/2013/03/kamailio-as-an-sbc-session-border-controller/

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License