In this post I will show you how to connect a pbx, with only an analog trunk available, to Portech MV-370 Gateway SIP/GSM, using a Grandstream HT503 gateway SIP/Analog FXO/FXS.
Tag Archives: Voip
Turn Pbx in a Flash 2.0.6.22 in RAID1 system
I have installed a brand new pbx (using Pbx in a flash), all works fine, but I want to turn the working setup in RAID1.
Att.: With the new releases of the PiaF setup is no longer possible to perform a RAID installation (option ks_sataraid), and in spite of the usefulness of the raid on a pbx is much discussed (see link to the Pbx in a flash forum below). I prefer always to use a RAID1 in “important” installation and when the pbx will be used like file server too. And when it is not possible to use a RAID controller, I use Linux software RAID (it is, however, better than nothing !).
I found the how-to “How To Create A RAID1 Setup On An Existing CentOS/RedHat 6.0 System“ in how to forge (see link below), and in this tutorial I adapted it for our purposes.
From SIP to RTP (Part 6) – The phone is ringing….
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
From SIP to RTP (Part 5) – Trunks & surroundings
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