Real Case: Asterisk receive an external call
A call from an external number to our pbx using a SIP trunk.
Att: I have “sniffed” that traffic using tcpdump.

tcpdump -i <interface> -s 65535 -w <file name>

In the next the Asterisk pbx is inside a LAN network, and its ip address is 10.10.10.110. The router in the network is configured with a public ip address 79.14.212.52. Asterisk is configured correctly using local network & public network parameters: in this mode all the message in SIP will be correctly valuated.

File sip.conf

[general]
externip = 79.14.212.52
localnet=10.10.10.0/255.255.255.0

>>Message from ISTP provider (IP 212.97.59.76) to Pbx (ip: 10.10.10.110)

INVITE sip:5224851@79.14.212.52 SIP/2.0
Record-Route: <sip:212.97.59.76:5061;lr=on;ftag=as16df4853;rpp=np>
Via: SIP/2.0/UDP 212.97.59.76:5061;branch=z9hG4bKc7f1.f1fb7516.1
Via: SIP/2.0/UDP 212.97.59.85:5060;branch=z9hG4bK683ee34f;rport=5060
From: "+393461050897" <sip:+393461050897@sip.messagenet.it>;tag=as16df4853
To: <sip:01042064023@212.97.59.76:5061>
Contact: <sip:+393461050897@212.97.59.85>
Call-ID: 509017dd3847bf900f839d877abfd752@sip.messagenet.it
CSeq: 102 INVITE
User-Agent: foxtrot
Max-Forwards: 69
Date: Tue, 29 Nov 2011 00:29:39 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 356
v=0
o=root 21598 21598 IN IP4 193.227.104.40
s=session
c=IN IP4 193.227.104.40
t=0 0
m=audio 35936 RTP/AVP 18 3 97 8 0 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

The trace show an incoming call from number +393461050897 to our number (trunk with ITSP) that is 01042064023.

Att.: 5224851 is another internal number assigned from ITSP to the trunk that is linked to 01042064023: very commonly the ITSP use this “internal number” for REGISTER & OPTIONS messages.

Att.: The ITSP know where is located the our pbx because Asterisk send periodically a REGISTER & OPTIONS messages: the NAT is “opened” by this kind of messages.

The ITSP wants to receive the voice streaming to 193.227.104.40 port 35936.

Att: Very interesting the UA that receive the voice stream is different from the UA that establish the call (different ip address): it is very common using big ITSP.

>> Messages from PBX (ip 10.10.10.110) to ISTP provider (IP 212.97.59.76).

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 212.97.59.76:5061;branch=z9hG4bKc7f1.f1fb7516.1;received=212.97.59.76
Via: SIP/2.0/UDP 212.97.59.85:5060;branch=z9hG4bK683ee34f;rport=5060
Record-Route: <sip:212.97.59.76:5061;lr=on;ftag=as16df4853;rpp=np>
From: "+393461050897" <sip:+393461050897@sip.messagenet.it>;tag=as16df4853
To: <sip:01042064023@212.97.59.76:5061>
Call-ID: 509017dd3847bf900f839d877abfd752@sip.messagenet.it
CSeq: 102 INVITE
User-Agent: FPBX-2.8.1(1.4.40)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: <sip:5224851@79.14.212.52>
Content-Length: 0

>> Messages from PBX (ip 10.10.10.110) to ISTP provider (IP 212.97.59.76).

SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.97.59.76:5061;branch=z9hG4bKc7f1.f1fb7516.1;received=212.97.59.76
Via: SIP/2.0/UDP 212.97.59.85:5060;branch=z9hG4bK683ee34f;rport=5060
Record-Route: <sip:212.97.59.76:5061;lr=on;ftag=as16df4853;rpp=np>
From: "+393461050897" <sip:+393461050897@sip.messagenet.it>;tag=as16df4853
To: <sip:01042064023@212.97.59.76:5061>;tag=as5dfb4137
Call-ID: 509017dd3847bf900f839d877abfd752@sip.messagenet.it
CSeq: 102 INVITE
User-Agent: FPBX-2.8.1(1.4.40)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: <sip:5224851@79.14.212.52>
Content-Type: application/sdp
Content-Length: 238
v=0
o=root 2754 2754 IN IP4 79.14.212.52
s=session
c=IN IP4 79.14.212.52
t=0 0
m=audio 18480 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

>>Final ACK

ACK sip:5224851@79.14.212.52 SIP/2.0
Record-Route: <sip:212.97.59.76:5061;lr=on;ftag=as16df4853>
Via: SIP/2.0/UDP 212.97.59.76:5061;branch=0
Via: SIP/2.0/UDP 212.97.59.85:5060;branch=z9hG4bK0bbcf9cd;rport=5060
From: "+393461050897" <sip:+393461050897@sip.messagenet.it>;tag=as16df4853
To: <sip:01042064023@212.97.59.76:5061>;tag=as5dfb4137
Contact: <sip:+393461050897@212.97.59.85>
Call-ID: 509017dd3847bf900f839d877abfd752@sip.messagenet.it
CSeq: 102 ACK
User-Agent: foxtrot
Max-Forwards: 69
Content-Length: 0

Asterisk accepts the call and declare that want to receive voice stream to 79.14.212.52 port 18480.

Now start the voice streaming: in this figure this traffic “sniffed” and showed using wireshark.

PBX → ITSP
10.10.10.110 – src port 1840 → 193.227.104.40 dst port 35936

ITSP → PBX
193.227.104.40 src port 35936 → 10.10.10.110 – dst port 1840

We can see that Asterisk start to send packet: in this mode the NAT open the port correctly and the ITSP can reach the Asterisk PBX inside the LAN.

Another very interesting things is that tha ITSP UA use a different Ip Address for the SIP messages and for the RTP stream.

Antother Real Case: Interconnection Asterisk<->Avaya/Nortel BCM 450
In this case an external connected to an Avaya Pbx BCM450 call using SIP an Asterisk PBX.

Asterisk PBX – IP 10.10.10.110
Avaya PBX – IP 10.10.10.155
Extent connected to Avaya PBX that establish the call – IP 10.10.10.87

>> From Avaya to Asterisk

INVITE sip:420;phone-context=subscriber.private@10.10.10.110:5060;transport=udp;user=phone SIP/2.0
From: <sip:anonymous@anonymous.invalid>;tag=34e03fa8-a0a0a9b-13c4-55013-59a-5708f3a4-59a
To: <sip:420;phone-context=subscriber.private@10.10.10.110;user=phone>
Call-ID: 35036840-a0a0a9b-13c4-55013-59a-3609da9e-59a
CSeq: 1 INVITE
Via: SIP/2.0/UDP 10.10.10.155:5060;branch=z9hG4bK-59a-15e419-1faa1b5d
Max-Forwards: 70
Supported: sipvc,x-nortel-sipvc,100rel,replaces
User-Agent: Nortel Networks BCM VoIP Gateway release_46 version_46.46.0.33
P-Asserted-Identity: <sip:anonymous@10.10.10.155>
Privacy: id;user
x-nt-corr-id: 35036840-a0a0a9b-13c4-55013-59a-3609da9e-59a
Contact: <sip:anonymous@anonymous.invalid:5060;maddr=10.10.10.155;transport=udp>
Allow: INVITE,INFO,ACK,OPTIONS,CANCEL,BYE,NOTIFY,PRACK,UPDATE,REFER
Content-Type: application/sdp
Content-Length: 334
v=0
o=- 1323100317 1323100317 IN IP4 10.10.10.155
s=-
c=IN IP4 10.10.10.87
t=0 0
a=sqn:0
a=cdsc:1 image udptl t38
m=audio 51000 RTP/AVP 18 4 0 8 120 111
c=IN IP4 10.10.10.87
a=fmtp:18 annexb=yes
a=fmtp:4 annexa=yes
a=rtpmap:120 telephone-event/8000
a=fmtp:120 0-15
a=rtpmap:111 X-nt-inforeq/8000
a=ptime:30
a=sendrecv

Asterisk -> Avaya

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 10.10.10.155:5060;branch=z9hG4bK-59a-15e419-1faa1b5d;received=10.10.10.155
From: <sip:anonymous@anonymous.invalid>;tag=34e03fa8-a0a0a9b-13c4-55013-59a-5708f3a4-59a
To: <sip:420;phone-context=subscriber.private@10.10.10.110;user=phone>
Call-ID: 35036840-a0a0a9b-13c4-55013-59a-3609da9e-59a
CSeq: 1 INVITE
User-Agent: FPBX-2.8.1(1.4.40)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: <sip:420@10.10.10.110>
Content-Length: 0

From Asterisk to Avaya

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.155:5060;branch=z9hG4bK-59a-15e419-1faa1b5d;received=10.10.10.155
From: <sip:anonymous@anonymous.invalid>;tag=34e03fa8-a0a0a9b-13c4-55013-59a-5708f3a4-59a
To: <sip:420;phone-context=subscriber.private@10.10.10.110;user=phone>;tag=as5b7d8e50
Call-ID: 35036840-a0a0a9b-13c4-55013-59a-3609da9e-59a
CSeq: 1 INVITE
User-Agent: FPBX-2.8.1(1.4.40)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: <sip:420@10.10.10.110>
Content-Type: application/sdp
Content-Length: 206
v=0
o=root 2756 2756 IN IP4 10.10.10.110
s=session
c=IN IP4 10.10.10.110
t=0 0
m=audio 16316 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

It is possible to verify with this Sip packet that the BCM 450 does not behave like a B2BUA: the asterisk pbx & extent of Avaya/Nortel BCM 450 connect itself each other directly !

PREVIOUS POST: From Sip to RTP (Part 5) – Trunks & surroundings

Linkografia
http://www.ietf.org/rfc/rfc3325.txt
http://en.wikipedia.org/wiki/Session_Initiation_Protocol

Definition of Trunks
Trunk lines are the phone lines coming into the PBX from the telephone provider. Trunking saves cost, because there are usually fewer trunk lines than extension lines, since it is unusual in most offices to have all extension lines in use for external calls at once.

Att.: Definition partially taken from Wikipedia (http://en.wikipedia.org/wiki/Trunking)
Att.: Normally it is possible to use the ratio 1:5 for trunks:extensions.

Similarly a Sip Trunk is a service offered by an ITSP (Internet Telephony Service Provider) that permits businesses that have a PBX installed to call outside the enterprise network to all phone in the public network (SIP or not) by using the same connection as the Internet connection, .

In the other words if Bob, that use a SIP Pbx, want to call Ada, and Ada’s phone is an old-fashioned analog phone, the Bob’s Pbx must use a trunk line and a service offered by an ITSP.

NAT & SIP
It is impossible tell about SIP & SDP/RTP without mentioning problems related to NAT and the problems it can introduce.

Att.: If the pbx, phone, and other related devices are all in the same LAN, the NAT it is not involved, and it is possible to not know anything about these problems. But very often the pbx use a trunk that is connected to ITSP, and the connection very often traverse a NAT device: in this case the NAT interfere with this process.

NAT (Network Address Translation or Network Address Translator) is the process of translation of an Internet Protocol address (IP address) used within one network (i.e. internal LAN) to a different IP address known within another network (i.e. WAN, that is the “external network”). Typically, an office maps its local inside network addresses that accesses to internet to one or more global outside IP addresses and unmaps the global IP addresses on incoming packets back into local IP addresses. NAT conserves on the number of global IP addresses that a company needs to connects to internet, and it lets the company use up to a single IP address: this address is often used by the router that connects the computers to the Internet.

The simplest type of NAT provides a one to one translation of IP addresses (basic NAT or one-to-one NAT). In this type of NAT only the IP addresses, IP header checksum and any higher level checksums that include the IP address need to be changed. The rest of the packet can be left untouched (at least for basic TCP/UDP functionality, some higher level protocols may need further translation). Basic NATs can be used when there is a requirement to interconnect two IP networks with incompatible addressing.

However it is common to hide an entire IP address space, usually consisting of private IP addresses, behind a single IP address (or in some cases a small group of IP addresses) in another (usually public) address space. To avoid ambiguity in the handling of returned packets, a one-to-many NAT must alter higher level information such as TCP/UDP ports in outgoing communications and must maintain a translation table so that return packets can be correctly translated back. The term for this kind of NAT are NAPT (network address and port translation), PAT (port address translation), IP masquerading, NAT Overload and many-to-one NAT.

Att.: Since this is the most common type of NAT it is often referred to simply as NAT.

As described, the method enables communication through the router only when the conversation originates in the masqueraded network, since this establishes the translation tables. For example, a web browser in the masqueraded network can browse a website outside, but a web browser outside could not browse a web site in the masqueraded network. However, most NAT devices today allow the network administrator to configure translation table entries for permanent use. This feature is often referred to as “static NAT” or port forwarding and allows traffic originating in the “outside” network to reach designated hosts in the masqueraded network.

We have to tell that SIP & SDP/RTP are good protocols, but things kind of break down when NAT gets involved. SIP packets themselves tend to move about without too much trouble (generally), as they ‘hop’ from one server to another: RTP sessions (voice transport) are somewhat more troublesome. The reason is that the NAT modify the port and the address of the Ip protocols, left unchanged the SDP/RTP packets, and it lead to inconsistent message between devices.

Either both clients need to be aware they are behind a NAT, and substitute their local IP addresses for their public IPs in their Session Description messages (the messages that specify the ip address/port to use to transmit voice stream) and open the appropriate firewall ports, or something has to modify the SIP packets en route.

Alternatively it is possible to use NAT device that are equipped with SIP proxy (i.e. siproxd) that intercept all the SIP/SDP/RTP packet and check the used Ip address, substitute the wrong value and retransmit the packet and “open the port” in the NAT for the incoming streaming audio.

Att: Very often if the SIP UA does not modify the Ip address in SIP/SDP message, and the NAT device is not using a Sip proxy, and all works fine too: it depends on the kind of the NAT that the LAN is in using, and if the receiver of the SIP/SDP message is capable of handle message with private local Ip address in SIP/SDP message.

Products known as Back-to-Back User Agents (i.e. Asterisk), can actually proxy RTP traffic: Asterisk can modify SIP packets to direct the caller and destination to establish an RTP session with itself, rather than with each other. This is useful in situations where two SIP clients may not have direct access to each other, most commonly, when one or both of the SIP clients are behind a NAT.

The argument SIP & NAT is very difficult, and to truly understand something to be studied in depth and much documentation. In general, to avoid any problem when possible is always best to use the pbx with a public IP address to connect to ITSP, but this leads to problems relating to safety.

Otherwise in the next some advice.
– Configure the pbx to substitute their local IP addresses for their public IPs in their Session Description messages and related messages
– Configure the pbx to transmit periodically an OPTION packet to the ITSP
– If you have differente devices that connect to external ITSP using SIP you have to modify the originating port used by the protocol: every devices must use a unique different port.
– If you can configure router create static NAT to forward to the pbx all the ports used by the SIP protocol & RDP stream.

PREVIOUS POST: From Sip to RTP (Part 4) – Invite & Register friendship
NEXT POST:  From SIP to RTP (Part 6) – The phone is ringing….

Linkografia
http://www.techterms.com/definition/nat
http://en.wikipedia.org/wiki/Network_address_translation

INVITE
Session Call Establishment

Sip: Alice wants to call Bob

Call Flow

1. The UAC (Alice) sends an INVITE message to Bob (UAS).
2. The UAS receives the request and responds using 100 Trying.
3. The UAS sends message 180 Ringing response to UAC when the phone begins ringing.
4. Once the call is picked up, the UAS send a 200 Ok message to the UAC.
5. The UAC sends an ACK request to confirm the 200 Ok response was received.

Note: The ACK method completes what is known as the three-way handshake-confirmation that a session has been successfully established. In SIP the INVITE is the only method where this occurs, and this is due to the large gap of time that often occurs between the INVITE itself and the 200 OK response (when a user can’t find the phone, is running to the phone, etc.). So the ACK it is important: it tells the callee party that the caller hasn’t hung up and has accepted the call.

Real Example
Alice -> Bob

INVITE sip:41@pbx.company-alice-and-bob.com;user=phone SIP/2.0
Via: SIP/2.0/TLS 10.10.10.32:2061;branch=z9hG4bK-9gg3wzak;rport
From: “Alice” <sip:40@pbx.company-alice-and-bob.com>;tag=g5ua0i7fz6
To: <sip:41@pbx.company-alice-and-bob.com;user=phone>
Call-ID: 3c2812339279-zvojwzvof6we
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:40@10.10.10.32:2061;transport=tls;line=i339wesg>;reg-id=1
P-Key-Flags: resolution=”31x13”, keys=”4”
User-Agent: snom360/7.3.14
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Content-Length: 452

Bob -> Alice

SIP/2.0 100 Trying
Via: SIP/2.0/TLS 10.10.10.32:2061;branch=z9hG4bK-9gohvng3wzak;rport=2061
From: “Alice” <sip:40@pbx.company-alice-and-bob.com>;tag=g5ua0i7fz6
To: <sip:41@pbx.company-alice-and-bob.com;user=phone>;tag=eed7a3b4e0
Call-ID: 3c2812339279-zvojwzvof6we
CSeq: 1 INVITE
Content-Length: 0

Bob -> Alice

SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 10.10.10.34:5060;branch=z9hG4bKe299f160c512cb066a3a536253aa4d44;rport=5061
From: "Bob" <sip:41@pbx.company-alice-and-bob.com>;tag=ozac09qwnh
To: “Alice” <sip:40@pbx.company-alice-and-bob.com>;tag=1521860827
Call-ID: f6f17567@pbx
CSeq: 28592 INVITE
Contact: <sip:41@10.10.10.31:1037;transport=tls;line=zs4m8lei>;reg-id=1
Require: 100rel
RSeq: 1
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer, call-info
Content-Length: 0

Alice -> Bob

SIP/2.0 200 Ok
Via: SIP/2.0/TLS 10.10.10.34:5060;branch=z9hG4bK-08d0f56ed1e8d82deb32779c5a2cc55b;rport=5061
From: “Alice” <sip:40@pbx.company-alice-and-bob.com>;tag=1521860827
To: "Bob" <sip:41@pbx.company-alice-and-bob.com>;tag=ozac09qwnh
Call-ID: f6f17567@pbx
CSeq: 28593 PRACK
Contact: <sip:41@10.10.10.31:1037;transport=tls;line=zs4m8lei>;reg-id=1
Content-Length: 0

Bob -> Alice

ACK sip:41@10.10.10.31:1037 ;transport=tls;line=zs4m8lei SIP/2.0
Via: SIP/2.0/TLS 10.10.10.34:5060;branch=z9hG4bK-6dcf1018159b8e96b7b6d62a758d77fd;rport
From: "Bob" <sip:41@pbx.company-alice-and-bob.com>;tag=ozac09qwnh
To: “Alice” <sip:40@pbx.company-alice-and-bob.com>;tag=1521860827
Call-ID: f6f17567@pbx
CSeq: 28592 ACK
Max-Forwards: 70
Contact: <sip:41@10.10.10.34:5060;transport=tls>
Content-Length: 0

Att.: Note: The “user=phone” parameter indicates that the user portion of the URI (the part to the left of the @ sign) should be treated as a tel URI: so 40 is the number assigned to the Alice’s phone, and 41 to Bob’s phone. Generally if dial a telephone number on a keypad, this is converted into a SIP URI of the form sip:nnnnn@domain;user=phone (in this case Alice dialed 41 using the keypad of the her phone to call Bob).

REGISTER
While going through a typical SIP session the proxy servers do the job of finding out the exact location of the recipient, and must be knows the ip address of the recipient UA. What actually happens is that every user registers its current location to a REGISTRAR server. The application sends a message callee REGISTER informing the server of its present location. The Registrar stores this binding (between the user and its present address) in a location server which is used by other proxies to locate the user.

The register process is very important because permit to bind UA ↔ Ip Address where the UA itself answer to INVITE etc. In the registration process it is possible to use an authentication (realm, username, password), but it is not mandatory.

Real Example

Alice -> Registrar Server

REGISTER sip:10.10.10.110:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.81:5060;branch=z9hG4bK97f7825d2
Max-Forwards: 70
Content-Length: 0
To: 40 <sip:40@10.10.10.110:5060>
From: 40 <sip:40@10.10.10.110:5060>;tag=60b2a3eb3e07b6e
Call-ID: b72007f19f018538b3ac254fa026dbb8@10.10.10.81
CSeq: 1507731226 REGISTER
Contact: 40 <sip:40@10.10.10.81:5060;transport=udp>;expires=120
Allow-Events: talk,hold,conference
Allow:NOTIFY,REFER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO
Authorization:Digest response="368b75e6f3d7244fbbf01da27b271feb",username="40",realm="asterisk",nonce="3b2d808b",algorithm=MD5,uri="sip:10.10.10.110:5060"
User-Agent: Aastra 9112i/1.4.3.1001 Brcm Callctrl/1.5.1.0 MxSF/v3.2.8.45

Registrar Server -> Alice

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.10.10.81:5060;branch=z9hG4bK97f7825d2;received=10.10.10.81
From: 40 <sip:40@10.10.10.110:5060>;tag=60b2a3eb3e07b6e
To: 40 <sip:40@10.10.10.110:5060>;tag=as2efd2925
Call-ID: b72007f19f018538b3ac254fa026dbb8@10.10.10.81
CSeq: 1507731226 REGISTER
User-Agent: FPBX-2.8.1(1.4.40)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="7e318af4"
Content-Length: 0

Alice -> Registrar Server

REGISTER sip:10.10.10.110:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.81:5060;branch=z9hG4bK824b13bb5
Max-Forwards: 70
Content-Length: 0
To: 40 <sip:40@10.10.10.110:5060>
From: 40 <sip:40@10.10.10.110:5060>;tag=60b2a3eb3e07b6e
Call-ID: b72007f19f018538b3ac254fa026dbb8@10.10.10.81
CSeq: 1507731227 REGISTER
Contact: 40 <sip:40@10.10.10.81:5060;transport=udp>;expires=120
Allow-Events: talk,hold,conference
Allow:NOTIFY,REFER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO
Authorization:Digest response="50d379545b2fd91e1a132eb42b120cf0",username="40",realm="asterisk",nonce="7e318af4",algorithm=MD5,uri="sip:10.10.10.110:5060"
User-Agent: Aastra 9112i/1.4.3.1001 Brcm Callctrl/1.5.1.0 MxSF/v3.2.8.45

Registrar Server -> Alice

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.81:5060;branch=z9hG4bK824b13bb5;received=10.10.10.81
From: 40 <sip:40@10.10.10.110:5060>;tag=60b2a3eb3e07b6e
To: 40 <sip:40@10.10.10.110:5060>;tag=as2efd2925
Call-ID: b72007f19f018538b3ac254fa026dbb8@10.10.10.81
CSeq: 1507731227 REGISTER
User-Agent: FPBX-2.8.1(1.4.40)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Expires: 120
Contact: <sip:40@10.10.10.81:5060;transport=udp>;expires=120
Date: Tue, 29 Nov 2011 00:29:34 GMT
Content-Length: 0

The authentication process checks that both communicate parties know a shared password. In the response 401 Unauthorized the server rejects the client registration and sends it back a challenge digest composed of an algorithm type, a realm and a nonce. When the client sends a new registration request but this time with a digest response composed of the:
”username”, “realm”, “nonce”, “uri”, “response” and the algorithm: the response is computed using the algorithm type, the nonce, the realm and the password. Now the server server will check the response using the password (that is the shared secret) 
for that user, and if all is correct it will send a OK message.

While going through a typical SIP session you have already seen that the caller doesn’t know the address of the callee initially. The proxy servers do the job of finding out the exact location of the recipient (ip address). What actually happens is that every user registers its current location to a REGISTRAR server. The application sends a message callee REGISTER informing the server of its present location. The Registrar stores this binding (between the user and its present ip address) in a location server which is used by other proxies to locate the user.

Att.: The Contact field in INVITE and others SIP-messages is related to the same field used in REGISTER method.

Att.: The ‘Expire’ field reflects the duration for which this registration (bind UA<->Ip Address) will be valid. So the UA has to refresh its registration from time to time.

OPTIONS
The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported SIP methods, codecs, etc. without call the other party.

For example, before a client inserts a field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field. All UAs MUST support the OPTIONS method !

Other use is to check the availability of an UA. I.e. it is possible bind statically an UA with a ip address: in this case the UA will not register himself. Using the OPTIONS message it is possible to verify that the UAS is on-line.

Att.: The UAs that register himself will receive the OPTIONS message too !

Real Example

The PBX send a OPTION message to an UA

OPTIONS sip:202@10.10.10.81:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.10.10.110:5060;branch=z9hG4bK026408ff;rport
From: "Unknown" <sip:Unknown@10.10.10.110>;tag=as264d051f
To: <sip:202@10.10.10.81:5060;transport=udp>
Contact: <sip:Unknown@10.10.10.110>
Call-ID: 787c4d983b006a5a3011bd356140ed15@10.10.10.110
CSeq: 102 OPTIONS
User-Agent: FPBX-2.8.1(1.4.40)
Max-Forwards: 70
Date: Tue, 29 Nov 2011 00:29:34 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0

Response from UA

SIP/2.0 200 OK
Call-ID: 787c4d983b006a5a3011bd356140ed15@10.10.10.110
CSeq: 102 OPTIONS
From: "Unknown" <sip:Unknown@10.10.10.110>;tag=as264d051f
To: <sip:202@10.10.10.81:5060>;tag=4fe041f88ba9bed
Via: SIP/2.0/UDP 10.10.10.110:5060;branch=z9hG4bK026408ff;rport
Content-Length: 0
Allow:NOTIFY,REFER,OPTIONS,INVITE,ACK,CANCEL,BYE,INFO
Contact: <sip:202@10.10.10.81:5060;transport=udp>
Supported: replaces
User-Agent: Aastra 9112i/1.4.3.1001 Brcm Callctrl/1.5.1.0 MxSF/v3.2.8.45

In this case the UA inform that it exist and support the below SIP message.

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Att.: Generally OPTION is sent regularly to all UA from the PBX, whether they are registered or not (Ip Address binded statically to UA). In asterisk it is possible modify this behavior with the qualify parameter. If you turn on qualify in the configuration of a SIP device in sip.conf, Asterisk will send a SIP OPTIONS command regularly to check that the device is still online. If the device does not answer within the configured period (in ms) Asterisk considers the device off-line for future calls. This status can be checked by in Asterisk with the command sip show peers: this will provide status information for peers which have qualify=yes (in status information there is a column that show the delay in response to OPTION message, that is a measure in connection latency between device and Pbx).

Att.: It is possible to use OPTION to try to solve NAT problem in order to keep open the connection from Asterisk to the peer behind NAT. I will write about SIP Pbx protected by Firewall/NAT in future posts.

PREVIOUS POST: From Sip tot RTP (Part 3) – B2BUA… What ?!
NEXT POST:  From SIP to RTP (Part 5) – Trunks and surroundings

Def. of Back-to-Back User Agent (B2BUA).
A B2BUA essentially bolts two user agents together in a back-to-back fashion, similar to two people standing back to back. A B2BAU establishes a two-legged call, keeping the SIP server in the middle of the call to orchestrate the details.

One side of the session acts as the SIP UA server that receives the calls; the other side acts as the SIP UA client that establishes the other leg of the call. This “middle position” of the SIP server allows the system to execute difficult call scenarios, like recording a call, stepping out of the voicemail system (by pressing 0), barging into a call, and many other call scenarios that are very hard to do without this center position.

Att.: Typically Asterisk (and most of the pbx) acts like a B2BUA, although you can configure it to behave differently.

In short a SIP call using a B2BUA can be described as the following: both Alice and Bob register to B2BUA Pbx.

If Alice wants to initiate a call with Bob, she will send an INVITE message (a call request) to B2BUA Pbx: it will then send the INVITE message to Bob’s ip phone (B2BUA Pbx knows the ip address where is located the Bob’s ip phone: we will see in details this step).

When Bob ip phone accepts the INVITE (answer the call), then he will send back an OK message to B2BUA Pbx, which will propagate back to ALICE ip phone. Alice then sends an ACK to B2BUA Pbx, that propagate to Bob’s ip phone: a media session that transport voice takes place from Alice’s Iphone → B2BUA Pbx → Bob’s Ip phone to transport the Alice voice, and Bob’s Ip Phone → B2BUA Pbx → Alice’s ip phone to transport the Bob’s voice. B2BUA Pbx in every call is in the middle !

Att.: It is important to note that pbx only proxy’s RTP media traffic when it has to, and when configured to do so: proxy’s RTP traffic is CPU/RAM intensive.

SIP Language
SIP shares some common characteristics with HTTP and SMTP. Like the latter two, SIP is an ASCII text-based protocol which makes it easy to read and troubleshoot. The text below is a SIP trace that shows a user inviting another use to a session.

Users are identified by a SIP address, known as a Uniform Resource Identifier (URI). A SIP URI is similar to an email address and is typically built around the user’s phone number or host name (e.g., sip:[your_number]@companyA.3tsistemi.it). This allows users to be redirected to another phone as easily as they would be redirected to another web page.

SIP communication consists of two types of SIP messages: methods and responses. Methods are sent from the client to the server and are used to indicate the purpose of the request. The following methods are the most important and common: there are some others but these are the must-be-known in trouble shutting process in SIP PBX environment.

INVITE
Establishes a session

ACK
Confirms an INVITE request

BYE
Ends a session

CANCEL
Cancels establishing of a session

REGISTER
Registers a Ip Phone with a registrar server (which is normally incorporated in the pbx: need to know the IP address of the phone, that is where to send the SIP messages)

OPTIONS
Communicates information about the capabilities of the other side.

Responses are sent from the server to the client and are used to indicate the status of the transaction. Responses are delivered in integer form (from 100 to 699) and are categorized as shown in the next.
1xx Informational responses
2xx Success responses
3xx Redirection responses
4xx Request failures
5xx Server errors
6xx Global failures

SIP messages consist of the following three parts:

SIP URI
The SIP URI is typically built around the user’s phone number.

This first line also indicates either the purpose of the request or the response given by the callee party

Message body
SIP requests and responses can both contain message bodies.

The content of the message body is usually a session description and contains syntax as shown in the message below.

Att: There are SIP message that does not have the Message Body, but only the Headers (i.e. Cancel, ACK).

Headers
SIP header fields provide additional information about the message. Common headers are shown below.

Via
Path taken by the request so far

Call ID
A unique number used to identify the call

CSeq
Used for keeping track of the conversation number in the SIP messages environment.

Contact
Used for identifying the user agent and the version of software used by the user agent.

Message Body
Normally contains the SDP messages.

PREVIOUS POST: From Sip to RTP (Part 2) – This is straight talking !
NEXT POST: From Sip tot RTP (Part 4) – Invite & Register friendship