Interoperability between IPv4 and IPv6 SIP User Agents

Transcription

1 Interoperability between IPv4 and IPv6 SIP User Agents Armin Brunner Head Communication Services Swiss Federal Institute of Technology Zürich Sabbatical-Project December 2003, January 2004 AARnet Canberra May 2004 AARnet Perth, Australia Abstract This report describes a working system to maintain SIP signaling and voice/video connectivity between SIP User Agents (Endpoints) with IPv4 or IPv6 only (not dual stack) network connectivity. The system is based on the well known and widely used open source SIP Express Router (SER). 1. Introduction Voice over IP (VoIP) based on the SIP signaling standard is becoming very popular in very different areas user groups. Especially in universities around the world there is a lot of interest in establishing Voice/Video systems based on SIP, preferably based on open source systems like Linux and SER (SIP Express Router, 1. Replacing POTS (Plain Old Telephone System) phones with network connected SIP phones needs at least as many new IP addresses as there are phones to be connected. If all these phones should be callable from everywhere via SIP (peer to peer model) they all need public addresses. Many organizations do not have enough IPv4 address space or are not willing to spend the necessary public addresses. The normal solution today is to use private IPv4 address space and establish a scheme to maintain connectivity with the public IPv4 world. There are several such schemes (see No such solution will be further discussed in this report. A much nicer and more future oriented approach would be to use public IPv6 addresses for this possibly large number of new network connected SIP- things. IPv6 is definitely coming but there will be some period of transition where other IPv4 phones have to call or to be called from these new IPv6 phones. The system to be designed should allow direct calls between public IPv4 phones and between public IPv6 phones as well. Calls between public IPv4 and IPv6 end systems should to be treated correctly and translated. 1 There is a very active Internt2 working group SIP.edu promoting SIP at universities (see ) proposing SER on Linux 1/29

2 IPv4 UA < > IPv4 UA IPv4 UA < > Translator < > IPv6 UA IPv6 UA < > Translator < > IPv4 UA IPv6 UA < > IPv6 UA Such a system should scale for large organizations. This means at least 1000 concurrent translated calls should be possible. 2. Introduction to SIP SIP is defined across several RFCs. The most important is RFC3261 which defines the core protocol. Examples of basic SIP protocol flows are in RFC3665. Probably the best collection of SIP related information can be found at There are several good introductions and tutorials available on the web. I found the SIP introduction from Jan Janak very useful ( In this introduction I describe only the very basic and simplified parts of SIP necessary to understand the described system. A SIP system consists of SIP User Agents (UA) and SIP Proxies. The UAs are the end systems (Clients) and the Proxies are the SIP protocol routers or Servers. (Sometimes the SIP Proxy is called a Softswitch or Software PBX. The function of the SIP Proxy is equivalent to the Gatekeeper in the H.323 world.) An organization normally has only one Proxy (maybe one more as backup) and as many UAs as users. The Proxies are necessary in the SIP signaling path to establish and terminate media sessions (audio and/or video) or to exchange instant messages between User Agents. The media streams between the end systems are (normally) over direct UDP connections between them and are independent from the Proxy infrastructure. The SIP signaling protocol is based on requests and answers. The two most important requests are INVITE to start and BYE to stop a session. The only answer of interest is OK. The INVITE and OK messages to establish a media session (phone call or video session) carry a so called SDP header to describe the media decoder the sending UA knows, and which IP number/port it is listening on to receive the UDP media stream sent from the other side. 2/29

3 The very basic and simplified signaling flow looks like this: UA1 Proxy UA2 F1 INVITE (sdp) > > F2 INVITE (sdp) > > (sdp) OK F3 < < (sdp) OK F4 < < SIP Session established. UDP Media Connection directly between UA1 and UA2 > > < < BYE F5 < < BYE F6 < < F7 OK > > F8 OK > > The session is initiated by UA1 with the invitation (for UA2) and SDP information (of UA1) in frame1 sent to the configured proxy. The proxy looks in its table of registered User Agents for the IP number of UA2 and resends the SIP message to UA2 (frame 2). UA2 sends an OK to accept the invitation (frame 3) and includes its media capabilities and listening port in the SDP header via Proxy (!) to UA1 (frame4). The SIP session is now established and each User Agent sends its encoded voice and/or video stream to the IP number and port in the received SDP header. UA2 wants to terminate the voice/video connection and sends a BYE via Proxy (!) to UA2 (frames 5 and 6) and stops sending the media stream to UA2. UA2 acknowledges (via Proxy) the BYE request with OK (frames 7 and 8), stops sending the media stream and closes its listening media port. UA2 closes its listening media port after receiving the OK from UA1. In reality things are a bit more complicated. A basic SIP trace including the flow chart and all packet decodes is attached in chapter 7.1 on page Discussion of the Problem and possible Solutions The signaling and media connection in a SIP environment today are normally based on public IPv4 addresses. All the User Agents and SIP Proxies must be IP-connectable to each other. If all the User Agents and Proxies are based on IPv6 addresses the system will work fine too. In case of a mixed system where some of the UAs are based on IPv4 and others on IPv6 addresses the situation is a bit different. There is no way for a direct IP connection between an IPv4 and an IPv6 system. But in a SIP environment such direct IP connections are fundamentally necessary between UAs and Proxies, between Proxies and between UAs. 3/29

4 The problem of IP connections between UAs and SIP-Proxies and connections between Proxies can be solved quite easily. If the SIP Proxies are equipped with dual IP stacks (IPv4 and IPv6 at the same time), the IPv6 and IPv4UAs can connect the same Proxy in their native IP version. All the User Agents have to register themselves with their Proxy in advance. If the Proxy has to contact a UA, the Proxy looks up its table of registered UAs and connects the UA in the native IP version of this UA. The connection between SIP Proxies can be based on the Domain Name System (DNS). If an AAAA (=IPv6) DNS request for the destination SIP Domain Name can be resolved, the IPv6 address of the destination Proxy will be used. If an AAAA request is not possible an A (=IPv4) DNS request is executed and the IPv4 address of the destination is used for the Proxy-Proxy connection. The described Proxy behavior is implemented in the actual production release (0.8.12) of SER and works without problems. The problem lies in the direct media connection between the User Agents. While with a very few Proxies it s still possible to have them dual stacked, with most User Agents this is not possible anymore. The UAs are IPv4 only or IPv6 only and a direct media connection between them is not possible. There needs to be a black box in between to translate IPv4 packets into IPv6 packets and vice-versa. Such translators exists in two principal flavors: NAT-PT or NATPT-PT devices (defined in RFC2766) translate on the fly on the Network level. They work quite similarly to the NAT devices we know that do address translation between public and private IPv4 address space (defined in RFC1631). NAT- PT devices change all the IPv4/IPv6 addresses in the IP header and in the protocol payload to their corresponding IPv6/IPv4 address. NAT-PT devices are fairly general but they have to have built in support for every protocol with IP addresses in the protocol payload (like SIP). Application Level Gateways (ALP) translate (surprisingly) on the Application level. In this context the Application is transferring media streams via UDP/RTP/RTCP. From the network point of view there are two independent media sessions between the translation box and the two User Agents. This Box receives the media stream over the IPv4 session, sends it unchanged (on Application level) over the IPv6 session and the same the other way round. Application Level Gateways are always specific for one protocol or protocol group. A working IPv4/IPv6 SIP system with NAT-PT has been described and demonstrated by J.W.Atwood et al in According to the author of the paper the biggest problem (and as yet unsolved hassle) are the two different IPv4 and IPv6 Domain Name Systems and the necessary and inescapable coordination between them. An outline of an IPv4/IPv6 SIP system with Application Level Gateway has been described by D.Sisalem and J.Fielder in a paper SIP and IPv6: Why and How? ( Unfortunately I discovered this paper very late in my project. In fact I developed a very similar system. There are some good things to say about the NAT-PT approach: It s possible to make it work. 4/29

5 NAT-PT can be implemented in hardware to make it scalable. The SIP support can be just a part of a more general IPv4/IPv6 interoperability scheme. Cons: In my scenario SIP is the only application and therefore a general approach is not necessary. Network Address Translation is EVIL and with IPv6 we want to get rid of it. During the IPv4/IPv6 transition phase I don t want to introduce new ones. I don t want to introduce and maintain additional Domain Name Servers to make the IPv4/IPv6 SIP system work. The Application Layer Gateway (ALG) approach has some goodies too: The SIP signaling traffic has to be routed through the Proxies anyway. Using the SIP Proxies for the IPv4/IPv6 translation of this signaling traffic is for free. The IPv4/IPv6 translation of the RTP media streams with an ALG software can be implemented in an extremely light weight way. More than 1000 parallel 64kbit/sec voice streams should be no problem for a decent (<2GHz x86) Linux computer parallel translated voice streams should be more than enough for an organization with phones. Cons: A specific solution for a specific application. I decided to use the Application Layer Gateway approach. 4. Description of nathelper/rtpproxy Nathelper is a module of the Sip Express Router (SER) originally intended to support SIP phones with private IP numbers behind a NAT device. Rtpproxy is the companion of the nathelper module to route the RTP media stream trough the same machine as SER (and nathelper) is running. Rtpproxy is controlled by nathelper through an internal Unix socket connection. The author of nathelper/rtpproxy is Maxim Sobolev (sobomax@portaone.com). The nathelper/rtpproxy combination includes most of the functions and functionalities I needed in my IPv4/IPv6 SIP Application Level Gateway. The SER module nathelper translates/rewrites all the necessary SIP and SDP header information and controls the rtpproxy which is the ALG for the UDP/RTP/RTCP media streams. I encouraged Maxim Sobolev with some sponsoring to program the necessary pieces: Finish the IPv6 support in nathelper and rtpproxy Support for remote rtpproxy (nathelper and rtpproxy on different machines for scalability) Support for bridging mode in nathelper and rtpproxy (ALG mode) These extensions are not yet included in the actual production release of SER (0.8.12). To use it, the CVS release (developer release) must be fetched either with the web browser 5/29

6 on or (better) with cvs itself (see ): In a shell: > set CVSROOT=:pserver:anonymous@cvs.berlios.de:/cvsroot/ser > export CVSROOT > cvs login and simply press enter when asked for password. > cvs co sip_router > cvs co rtpproxy Compile and install SER and rtpproxy according to the READMEs in the directories. I fetched the complete CVS in early May 004 (SER dev-28) and installed SER and rtpproxy in their default installation directories: SER binaries in /usr/local/sbin and configuration (ser.cfg) in /usr/local/etc/ser rtpproxy binary in /usr/local/bin By default SER keeps all the information about registered User Agents in volatile memory and they are lost after a restart of SER (which happens very often while debugging and making configuration changes). The UAs are then unreachable until they re-register. Some do this after a while, others don t. To keep the registry information persistent, mysql must be installed and the ser_mysql module must be activated and configured. If mysql is used, the mysql initialization script (/usr/local/sbin/ser_mysql.sh) has to be modified to create two additional tables (location_inet4 and location_inet6). These tables are used to store the registry information for IPv4 and IPv6 User Agents separately. Copy the part (at 47% of the file) CREATE TABLE location (... ) $TABLE_TYPE; twice and change the table name from location to location _inet4 and location_inet6. 5. Configuration Files and Command line Parameters In my test and demonstration system I used a dual stack Linux computer (SuSE 8.2) in Switzerland for the installation of SER and rtpproxy. The IP numbers of this computer are: and 2001:620:8:801:201:2ff:fe94:8e10 (DNS A and AAAA records of boostie.6dns.org). 5.1 Sip Express Router SER The SER configuration file I used is a working configuration, but not suitable for production. This config is for testing and demonstration purpose only. There is no authentication of User Agents or extended routing logic (dialing plan). Complete SER configurations file (/usr/local/etc/ser/ser.cfg): # # /usr/local/etc/ser/ser.cfg # 6/29

7 # simple quick-start config file with nathelper/rtpproxy # for IPv4/IPv6 gatewaying # # global configuration parameters debug=3 # debug level #fork=yes #log_stderror=no # check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=2 # count of ser processes per interface fifo="/tmp/ser_fifo" # # interfaces to listen for SIP traffic # the IPv6 address is necessary for IPv6 suport # default is all IPv4 interfaces listen= listen=2001:620:8:801:201:2ff:fe94:8e10 # # module loading loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" #Nathelper for RTPproxy loadmodule "/usr/local/lib/ser/modules/nathelper.so" # setting module-specific parameters # -- usrloc params -- #modparam("usrloc", "db_mode", 0) # Uncomment this if you want to use SQL database # for persistent storage and comment the previous line modparam("usrloc", "db_mode", 2) # username (ser) and password (heslo) for the local database # must correspond with username and password in the DB initialization # script /usr/local/sbin/ser_mysql.sh #modparam("usrloc", "db_url", "mysql://ser:heslo@localhost/ser") # -- auth params -- # Uncomment if you are using auth module # #modparam("auth_db", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter) # #modparam("auth_db", "password_column", "password") # -- rr params -- # add value to ;lr param to make some broken UAs happy 7/29

8 modparam("rr", "enable_full_lr", 1) # -- nathelper params -- modparam("nathelper", "rtpproxy_sock", "/var/run/rtpproxy.sock") # main fun below # domains to be recognized as myself alias=" " alias="2001:620:8:801:201:2ff:fe94:8e10" alias="boostie.6dns.org" alias="boostie.ethz.ch" alias="ethz.ch" route { # initial sanity checks -- messages with # max_forwars == 0, or excessively long requests, # or those that don't addressed to us if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); break; }; if (msg:len > max_len) { sl_send_reply("513", "Message too big"); break; }; # route invitation request to other domains if (!(uri == myself) && method == "INVITE") { record_route(); if (!t_relay()) sl_reply_error(); break; }; if (method == "REGISTER") { if (af == inet) { save("location_inet4"); } else if (af == inet6) { save("location_inet6"); } else { sl_send_reply("403", "Call cannot be served here"); }; break; }; if (method == "INVITE") { if (lookup("location_inet4")) { # Comment out three lines below if you want # RTP for IPv4->IPv4 calls to go directly # between UAs if (af == inet) if (force_rtp_proxy("faii")) t_on_reply("1"); # proxy session from a Internal IPv4 # phone to a External IPv6 address if (af == inet6) if (force_rtp_proxy("faie")) 8/29

9 t_on_reply("1"); } else if (lookup("location_inet6")) { # proxy session from a External IPv6 # phone to a Internal IPv4 address if (af == inet) if (force_rtp_proxy("faei")) t_on_reply("1"); # Comment out three lines below if you want # RTP for IPv6->IPv6 calls to go directly # between UAs if (af == inet6) if (force_rtp_proxy("faee")) t_on_reply("1"); } else { sl_send_reply("403", "Call cannot be served here"); break; }; }; if (method == "BYE" method == "CANCEL") unforce_rtp_proxy(); # Do strict routing if pre-loaded route headers present if (loose_route()) { t_relay(); break; }; if (method == "INVITE") record_route(); if (!t_relay()) sl_reply_error(); } onreply_route[1] { if (!(status=~"183" status=~"200")) break; force_rtp_proxy("fa"); } I started/stopped/restarted SER normally with the serctl application: > /usr/local/sbin/serctl start > /usr/local/sbin/serctl stop > /usr/local/sbin/serctl restart (Btw: serctl is a very helpful tool while testing). 5.2 rtpproxy I started rtpproxy with these options: > /usr/local/bin/rtpproxy -l / :620:8:801:201:2ff:fe94:8e10 The -l option names the IPv4 address and the -6 option names the IPv6 address of the rtpproxy. The argument for both options is IP-address/IP-address. The IP-address in front of the / is the external address and the IP-address after the / is the 9/29

10 internal address. Internal and external are meaningful only for the direction of the translation and are used in the nathelper-configuration inside ser.cfg. In my example, is the internal address and 2001:620:8:801:201:2ff:fe94:8e10 is the external address. The -f option is useful to keep rtpproxy in the foreground (rtpproxy normally forks into daemon mode). With rtpproxy in the foreground you can see the debug, error and statistical messages. By default the nathelper modules of SER and rtpproxy communicate via the Unix domain socket /var/run/rtpproxy.sock which means they have to run on the same computer. If for any reason SER and rtpproxy have to run on different computers nathelper and rtpproxy have to communicate via udp (ipv4) or udp6 (IPv6). In the SER config file (/usr/local/etc/ser/ser.cfg) you have to replace the line modparam("nathelper", "rtpproxy_sock", "/var/run/rtpproxy.sock") with modparam("nathelper", "rtpproxy_sock", "udp:ipv4-address:port") or modparam("nathelper", "rtpproxy_sock", "udp6:ipv6-address:port") where ipv4/ipv6-address is the IP address of the computer running rtpproxy. Port is optional, the default is The rtpproxy commandline must include the -s option. (See the file README.remote in the rtpproxy directory.) I tested the remote mode and it worked without any problem. 6. Tested User Agents and remaining Problems I worked successfully with the following User Agents: IPv4 on Windows XP SP1: - X-lite rel.1103a from - SJphone ver b from - Windows Messanger ver from IPv4 on MacOS X : - X-lite ver. 2.0 rel.1103a from - SJphone ver b from IPv4 on Linux (RedHat 9 and SuSE 9): - Kphone 4.0 from - SJphone ver b from IPv4 HW SIP Phone - Cisco 7960 with Firmware Ver IPv6 on Linux - Kphone 3.11-ipv6 from I tried several other UAs who claim to have IPv6 support with no success. But to be honest I did not invested much time in debugging: Linphone 0.12 from Sip-communicator from Vocal Sipset from resiprocate from BonPhone 0.8.9d from 10/29

11 6.1 Testresults IPv4 to IPv4 I had no problems with all the mentioned IPv4 User Agents. All of them could register with my SER installation and could call other UA s or be called through rtpproxy IPv6 to IPv6 The only IPv6 User Agent I managed to get working (more or less) was kphone-3.11-ipv6. Sessions between two such User Agents through rtpproxy worked fine without any problems IPv4 to IPv6 and vice-versa Sessions between kphone-3.11-ipv6 and an IPv4 User Agents depended on the IPv4 User Agents. With some it was no problem; with others it was not possible. The reason for this is quite simple. As mentioned in chapter 4, the nathelper module has to change certain fields in the SIP messages. In theory it should change all the fields with direct references to the IPnumber/port of a User Agent. These are the Contact: field in the SIP header and the originator (o=), the contact (c=) and the media descriptor (m=) in the SDP header. In reality nathelper changes only the c= and m= fields in the SDP header and leaves the SDP originator and SIP contact fields unchanged. This would be no problem if all the elements in the signaling path were programmed correctly. The SIP contact field should not be used because there is explicit route information in the SIP header (record_route) and the SDP contact field should not be used for anything. The reality is a bit different. At least the SIP Contact: field is interpreted even if not used by some User Agents and a call rejected or ignored if this field contains an uninterpretable IPv6 address (like the Cisco 7960 SIP phone or SJphone). This problem could easily be solved if nathelper at least changed the IP number in the SIP Contact: field to the same value like in the SDP c= field. The other problem is kphone-3.11-ip6 itself. This software is very buggy and crashes very often. On startup, kphone asks which IP numbers it should use to communicate. If I chose only the IPv6 address it was not possible to establish a connection to an IPv4 UA because kphone interprets the SIP Contact: field from the other side (=IPv4 address) and refuse to connect because kphone has no IPv4 address itself. So I used kphone most of the time with an IPv4 and IPv6 address at the same time. In this case kphone correctly prefers the IPv6 address and uses its IPv6 address in all header fields where an IP number is placed, except in the SIP Contact: field. This may explain the wrong behavior of the proxy at frames 12 and 14 of the IPv4/IPv6 trace in chapter 7.2 on page 19. If kphone is calling (IPv6/IPv4 trace in chapter 7.3 on page 25), kphone initially behaves correctly, using its IPv6 address in the SIP Contact: field but fails in frame 9 when it sends its ACK directly to the (IPv4) address in the SIP Contact: field from the other side. The problems with this bad behaviour could easily be lessened if the SIP Contact: field were treated correctly by nathelper. 11/29

12 6.1 Future work There is some further work needed to get this system into a more production-ready state: Convincing the author of nathelper, Maxim Sobolev, to include the SIP Contact: field in the fields to be treated (and maybe the SDP originator (o=) field also). The system has as yet only been tested in a single-proxy environment. The SER config file (ser.cfg) should be extended to handle multi-proxy environments correctly. This is no problem for sessions which don t need to be translated (IPv4-IPv4 or IPv6-IPv6) but needs some further work for translating sessions. Any real world environment includes some gateways to the PSTN world. This has not been tested yet with this system. But there are some other installations of SER working with different gateways. I think this should be no problem. It would be a good idea to include some authorization scheme in the system. There are quite good examples for that. This should be no real problem also. Any real world production needs a rather intelligent dialing plan. This can be a challenge. There is no really good, reliable IPv6 User Agent software available (at least I couldn t find it). I tried some without success but I didn t have the time to debug things if they didn t work after a few minutes. It s might be worth investing some more time in this area. If the scenario sketched in the Introduction (chapter 1) is to become reality, there need to be some cheap IPv6 hardware phones and IPv6 POTS adapter hardware available on the market. I know of some experimental work in Taiwan and Korea but I was not able to find the real people and companies behind these (glossy?) projects. The universities and other big companies around the world should demand of well established producers of VoIP equipment like Cisco and others that they include native IPv6 support in their products. Such a customer demand can easily succeed if there are enough requests. Every Request for Proposals for new VoIP equipment should request IPv6 support (or require it to be included in maybe 6 months). 12/29

13 7. Traces 7.1 Trace of a basic SIP Session (1 to 2, hang-up from 2) This is a trace of a very basic session without any special features between two IPv4 UA s at AARnet, Australia ( = sip:1@boostie.6dns.org and = sip:2@boostie.6dns.org) and the SIP proxy in Switzerland ( = boostie.6dns.org). Because of the long round trip delay between Australia and Switzerland some frames were retransmissions (F9, F11, F12, F14) and have been removed from the trace for clarity. The SDP headers in Frame 1/3 and Frame 7/8 carry the information for the RTP media connection. The c= field contains the IP number and the m= field the port number of the RTP listening port that this User Agents has opened to be called to from the other end <Call><PFrame><Time> F1 INVITE (sdp) > > 1 PF:1 10:09: Trying 100 F2 < < 1 PF:2 10:09: F3 INVITE (sdp) > > 1 PF:3 10:09: Trying 100 F4 < < 1 PF:4 10:09: Ringing 180 F5 < < 1 PF:5 10:09: Ringing 180 F6 < < 1 PF:6 10:09: (sdp) OK 200 F7 < < 1 PF:7 10:09: (sdp) OK 200 F8 < < 1 PF:8 10:09: F10 ACK > > 1 PF:10 10:09: F13 ACK > > 1 PF:13 10:09: SIP Session established. RTP Media Connection directly between and > > < < BYE F15 < < 1 PF:15 10:09: BYE F16 < < 1 PF:16 10:09: F Ok > > 1 PF:17 10:09: BYE F18 < < 1 PF:18 10:09: BYE F19 < < 1 PF:19 10:09: F Ok > > 1 PF:20 10:09: F Ok > > 1 PF:21 10:09: /29

14 ============== SIP MESSAGE :5060() -> :5060() UDP Frame 1 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= INVITE sip:2@boostie.6dns.org SIP/2.0 Via: SIP/2.0/UDP :5060;rport;branch=z9hG4bKE AACB11D8966C000393DB5E32 From: ArminMac <sip:1@boostie.6dns.org>;tag= To: <sip:2@boostie.6dns.org> CSeq: INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1103a Content-Length: 239 v=0 o= IN IP s=x-lite c=in IP t=0 0 m=audio 8000 RTP/AVP a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: ============== SIP MESSAGE :5060() -> :5060() UDP Frame 2 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= SIP/ trying -- your call is important to us Via: SIP/2.0/UDP :5060;rport=5060;branch=z9hG4bKE AACB11D8966C000393DB5E32 From: ArminMac <sip:1@boostie.6dns.org>;tag= To: <sip:2@boostie.6dns.org> CSeq: INVITE Server: Sip EXpress router ( dev-28 (i386/linux)) Warning: :5060 "Noisy feedback tells: pid=25476 req_src_ip= req_src_port=5060 in_uri=sip:2@boostie.6dns.org out_uri=sip:2@ :5060 via_cnt==1" ============== SIP MESSAGE :5060() -> :5060() UDP Frame 3 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= INVITE sip:2@ :5060 SIP/2.0 Record-Route: <sip: ;ftag= ;lr=on> Via: SIP/2.0/UDP ;branch=z9hG4bK491a.380ec8c1.0 Via: SIP/2.0/UDP :5060;rport=5060;branch=z9hG4bKE AACB11D8966C000393DB5E32 From: ArminMac <sip:1@boostie.6dns.org>;tag= To: <sip:2@boostie.6dns.org> CSeq: INVITE Max-Forwards: 69 Content-Type: application/sdp User-Agent: X-Lite release 1103a Content-Length: 239 v=0 o= IN IP s=x-lite c=in IP t=0 0 m=audio 8000 RTP/AVP a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: ============== 14/29

15 SIP MESSAGE :5060() -> :5060() UDP Frame 4 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= SIP/ Trying CSeq: INVITE From: <sip:1@boostie.6dns.org>;tag= To: "Armin Brunner"<sip:2@boostie.6dns.org>;tag= Server: SJLabs-SJphone/ b Via: SIP/2.0/UDP ;branch=z9hG4bK491a.380ec8c1.0,SIP/2.0/UDP :5060;branch=z9hG4bKE AACB11D8966C000393DB5E32;rport=5060 ============== SIP MESSAGE :5060() -> :5060() UDP Frame 5 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= SIP/ Ringing Contact: <sip:2@ :5060> CSeq: INVITE From: <sip:1@boostie.6dns.org>;tag= Record-Route: <sip: ;ftag= ;lr=on> To: "Armin Brunner"<sip:2@boostie.6dns.org>;tag= Server: SJLabs-SJphone/ b Via: SIP/2.0/UDP ;branch=z9hG4bK491a.380ec8c1.0,SIP/2.0/UDP :5060;branch=z9hG4bKE AACB11D8966C000393DB5E32;rport=5060 ============== SIP MESSAGE :5060() -> :5060() UDP Frame 6 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= SIP/ Ringing Contact: <sip:2@ :5060> CSeq: INVITE From: <sip:1@boostie.6dns.org>;tag= Record-Route: <sip: ;ftag= ;lr=on> To: "Armin Brunner"<sip:2@boostie.6dns.org>;tag= Server: SJLabs-SJphone/ b Via: SIP/2.0/UDP :5060;branch=z9hG4bKE AACB11D8966C000393DB5E32;rport=5060 ============== SIP MESSAGE :5060() -> :5060() UDP Frame 7 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= SIP/ OK Content-Length: 169 Contact: <sip:2@ :5060> Content-Type: application/sdp CSeq: INVITE From: <sip:1@boostie.6dns.org>;tag= Record-Route: <sip: ;ftag= ;lr=on> To: "Armin Brunner"<sip:2@boostie.6dns.org>;tag= Server: SJLabs-SJphone/ b Via: SIP/2.0/UDP ;branch=z9hG4bK491a.380ec8c1.0,SIP/2.0/UDP :5060;branch=z9hG4bKE AACB11D8966C000393DB5E32;rport=5060 v=0 o= IN IP s=c=in IP t=0 0 m=audio RTP/AVP a=rtpmap:101 telephone-event/8000 a=fmtp: ,16 ============== 15/29

16 SIP MESSAGE :5060() -> :5060() UDP Frame 8 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= SIP/ OK Content-Length: 169 Contact: <sip:2@ :5060> Content-Type: application/sdp CSeq: INVITE From: <sip:1@boostie.6dns.org>;tag= Record-Route: <sip: ;ftag= ;lr=on> To: "Armin Brunner"<sip:2@boostie.6dns.org>;tag= Server: SJLabs-SJphone/ b Via: SIP/2.0/UDP :5060;branch=z9hG4bKE AACB11D8966C000393DB5E32;rport=5060 v=0 o= IN IP s=c=in IP t=0 0 m=audio RTP/AVP a=rtpmap:101 telephone-event/8000 a=fmtp: ,16 ============== SIP MESSAGE :5060() -> :5060() UDP Frame 10 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= ACK sip:2@ :5060 SIP/2.0 Via: SIP/2.0/UDP :5060;rport;branch=z9hG4bKE366186FAACB11D8966C000393DB5E32 From: <sip:1@boostie.6dns.org>;tag= To: "Armin Brunner" <sip:2@boostie.6dns.org>;tag= Route: <sip: ;ftag= ;lr=on> CSeq: ACK Max-Forwards: 70 ============== SIP MESSAGE :5060() -> :5060() UDP Frame 13 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= ACK sip:2@ :5060 SIP/2.0 Via: SIP/2.0/UDP ;branch=0 Via: SIP/2.0/UDP :5060;rport=5060;branch=z9hG4bKE366186FAACB11D8966C000393DB5E32 From: <sip:1@boostie.6dns.org>;tag= To: "Armin Brunner" <sip:2@boostie.6dns.org>;tag= CSeq: ACK Max-Forwards: 69 ============== SIP MESSAGE :5060() -> :5060() UDP Frame 15 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= BYE sip:1@ :5060 SIP/2.0 Contact: <sip:2@ :5060> Max-Forwards: 70 CSeq: 1 BYE From: <sip:2@boostie.6dns.org>;tag= Route: <sip: ;ftag= ;lr=on> To: <sip:1@boostie.6dns.org>;tag= User-Agent: SJLabs-SJphone/ b Via: SIP/2.0/UDP :5060;branch=z9hG4bKca c9b140ad64db000002fb ============== 16/29

17 SIP MESSAGE :5060() -> :5060() UDP Frame 16 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= BYE SIP/2.0 Contact: Max-Forwards: 69 CSeq: 1 BYE From: <sip:2@boostie.6dns.org>;tag= To: <sip:1@boostie.6dns.org>;tag= User-Agent: SJLabs-SJphone/ b Via: SIP/2.0/UDP ;branch=z9hG4bKd88b.17fe1bd3.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bKca c9b140ad64db000002fb ============== SIP MESSAGE :5060() -> :5060() UDP Frame 17 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= SIP/ Ok Via: SIP/2.0/UDP ;branch=z9hG4bKd88b.17fe1bd3.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bKca c9b140ad64db000002fb From: <sip:2@boostie.6dns.org>;tag= To: <sip:1@boostie.6dns.org>;tag= CSeq: 1 BYE Server: X-Lite release 1103a ============== SIP MESSAGE :5060() -> :5060() UDP Frame 18 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= BYE sip:1@ :5060 SIP/2.0 Contact: <sip:2@ :5060> Max-Forwards: 70 CSeq: 1 BYE From: <sip:2@boostie.6dns.org>;tag= Route: <sip: ;ftag= ;lr=on> To: <sip:1@boostie.6dns.org>;tag= User-Agent: SJLabs-SJphone/ b Via: SIP/2.0/UDP :5060;branch=z9hG4bKca c9b140ad64db000002fb ============== SIP MESSAGE :5060() -> :5060() UDP Frame 19 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= BYE sip:1@ :5060 SIP/2.0 Contact: <sip:2@ :5060> Max-Forwards: 69 CSeq: 1 BYE From: <sip:2@boostie.6dns.org>;tag= To: <sip:1@boostie.6dns.org>;tag= User-Agent: SJLabs-SJphone/ b Via: SIP/2.0/UDP ;branch=z9hG4bKd88b.17fe1bd3.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bKca c9b140ad64db000002fb ============== SIP MESSAGE :5060() -> :5060() UDP Frame 20 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= SIP/ Ok Via: SIP/2.0/UDP :5060;branch=z9hG4bKca c9b140ad64db000002fb From: <sip:2@boostie.6dns.org>;tag= /29

18 To: CSeq: 1 BYE Server: X-Lite release 1103a ============== SIP MESSAGE :5060() -> :5060() UDP Frame 21 21/May/04 10:09: TimeFromPreviousSipFrame= TimeFromStart= SIP/ Ok Via: SIP/2.0/UDP :5060;branch=z9hG4bKca c9b140ad64db000002fb From: <sip:2@boostie.6dns.org>;tag= To: <sip:1@boostie.6dns.org>;tag= CSeq: 1 BYE Server: X-Lite release 1103a ============== ============== 18/29

19 7.2 Trace of a translated SIP-Session (1 to 6, hang-up from 1) This is a trace of a translated session with a nathelper/rtpproxy between two UA s at AARnet, Australia ( = sip:1@boostie.6dns.org and 2001:388:7000:4000:20c:29ff:fe85:39d1 = sip:6@boostie.6dns.org) and the SIP proxy in Switzerland ( /2001:620:8:801:201:2ff:fe94:8e10 = boostie.6dns.org). Because of the long round trip time between Australia and Switzerland some frames were retransmissions (F6, F8, F16, F17) and have been removed for clarity. The SDP headers in Frame 1/3 and Frame 9/10 carry the information for the RTP media connection. The c= field contains the IP number and the m= field the port number of the RTP listening port that this User Agent has opened to be called to from the other end. Because the RTP connection must be routed through the rtpproxy, the c= and m= fields must be modified on the fly in the SIP proxy (in the nathelper module). c=in IP m=audio 8000 RTP/AVP in Frame 1 becomes in Frame 3 c=in IP6 2001:620:8:801:201:2ff:fe94:8e10 m=audio RTP/AVP and c=in IP6 2001:388:7000:4000:20c:29ff:fe85:39d1 m=audio 162 RTP/AVP 0 3 in Frame 9 becomes in Frame 10 c=in IP m=audio RTP/AVP 0 3 These two changes make sure both UA s are connecting the rtpproxy running on /2001:620:8:801:201:2ff:fe94:8e10. Frames 12, 14, 15 are wrong (IPv4 instead of IPv6). See chapter for an explanation ( ) 2001:620:8:801:201:2ff:fe94:8e :388:7000:4000:20c:29ff:fe85:39d1 <Call><PFrame> F1 INVITE (sdp) > > 1 PF:1 Trying 100 F2 < < 1 PF:2 F3 INVITE (sdp) > > 1 PF:3 Trying 100 F4 < < 1 PF:4 Ringing 180 F5 < < 1 PF:5 Ringing 180 F7 < < 1 PF:7 (sdp) OK 200 F9 < < 1 PF:9 (sdp) OK 200 F10 < < 1 PF:10 F11 ACK > > 1 PF:11 F12 ACK > > 1 PF:12 IPv4 instead of IPv6 SIP Session established. UDP RTP Media Connection through rtpproxy at /2001:620:8:801:201:2ff:fe94:8e10 (IPv4 RTP between and ; IPv6 RTP between 2001:620:8:801:201:2ff:fe94:8e10 and 2001:388:7000:4000:20c:29ff:fe85:39d1 > IPv4-RTP > > IPv6-RTP > < IPv4-RTP < < IPv6-RTP < F13 BYE > > 1 PF:13 F14 BYE > > 1 PF:14 IPv4 instead of IPv6 OK 200 F15 < < 1 PF:15 IPv4 instead of IPv6 OK 200 F18 < < 1 PF:18 19/29

20 Frame 1 (716 bytes on wire, 716 bytes captured) Arrival Time: May 21, :58: Time delta from previous packet: seconds Time relative to first packet: seconds IPv4 Packet from to Request line: INVITE sip:6@boostie.6dns.org SIP/2.0 Method: INVITE Via: SIP/2.0/UDP :5060;rport;branch=z9hG4bK54F09626AAF411D8AA DB5E32 From: ArminMac <sip:1@boostie.6dns.org>;tag= To: <sip:6@boostie.6dns.org> Call-ID: 4E5C189B-AAF4-11D8-AA DB5E32@ CSeq: INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1103a Content-Length: 239 Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): IN IP Session Name (s): X-Lite Connection Information (c): IN IP Time Description, active time (t): 0 0 Media Description, name and address (m): audio 8000 RTP/AVP Media Attribute (a): rtpmap:0 pcmu/8000 Media Attribute (a): rtpmap:8 pcma/8000 Media Attribute (a): rtpmap:3 gsm/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp: Frame 2 (658 bytes on wire, 658 bytes captured) Arrival Time: May 21, :58: Time delta from previous packet: seconds Time relative to first packet: seconds IPv4 Packet from to Status line: SIP/ trying -- your call is important to us Status-Code: 100 Via: SIP/2.0/UDP :5060;rport=5060;branch=z9hG4bK54F09626AAF411D8AA DB5E32 From: ArminMac <sip:1@boostie.6dns.org>;tag= To: <sip:6@boostie.6dns.org> Call-ID: 4E5C189B-AAF4-11D8-AA DB5E32@ CSeq: INVITE Server: Sip EXpress router ( dev-28 (i386/linux)) Warning: :5060 "Noisy feedback tells: pid=27805 req_src_ip= req_src_port=5060 in_uri=sip:6@boostie.6dns.org out_uri=sip:root@[2001:388:7000:4000:20c:29ff:fe85:39d1];transport=udp via_cnt==1" Frame 3 (1053 bytes on wire, 1053 bytes captured) Arrival Time: May 21, :58: Time delta from previous packet: seconds Time relative to first packet: seconds IPv6 Packet from 2001:620:8:801:201:2ff:fe94:8e10 to 2001:388:7000:4000:20c:29ff:fe85:39d1 Request line: INVITE sip:root@[2001:388:7000:4000:20c:29ff:fe85:39d1];transport=udp SIP/2.0 Method: INVITE Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];r2=on;ftag= ;lr=on> Record-Route: <sip: ;r2=on;ftag= ;lr=on> Via: SIP/2.0/UDP [2001:620:8:801:201:2FF:FE94:8E10];branch=z9hG4bK8db8.38ac98c6.0 Via: SIP/2.0/UDP :5060;rport=5060;branch=z9hG4bK54F09626AAF411D8AA DB5E32 From: ArminMac <sip:1@boostie.6dns.org>;tag= To: <sip:6@boostie.6dns.org> 20/29

21 Call-ID: CSeq: INVITE Max-Forwards: 69 Content-Type: application/sdp User-Agent: X-Lite release 1103a Content-Length: 278 Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): IN IP Session Name (s): X-Lite Connection Information (c): IN IP6 2001:620:8:801:201:2ff:fe94:8e10 Time Description, active time (t): 0 0 Media Description, name and address (m): audio RTP/AVP Media Attribute (a): rtpmap:0 pcmu/8000 Media Attribute (a): rtpmap:8 pcma/8000 Media Attribute (a): rtpmap:3 gsm/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp: Media Attribute (a): nortpproxy:yes Frame 4 (664 bytes on wire, 664 bytes captured) Arrival Time: May 21, :58: Time delta from previous packet: seconds Time relative to first packet: seconds IPv6 Packet from 2001:388:7000:4000:20c:29ff:fe85:39d1 to 2001:620:8:801:201:2ff:fe94:8e10 Status line: SIP/ Trying Status-Code: 100 Via: SIP/2.0/UDP [2001:620:8:801:201:2FF:FE94:8E10];branch=z9hG4bK8db8.38ac98c6.0 Via: SIP/2.0/UDP ;branch=z9hG4bK54F09626AAF411D8AA DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag= CSeq: INVITE Call-ID: 4E5C189B-AAF4-11D8-AA DB5E32@ To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa User-Agent: KPhone/3.11 Contact: "root" <sip:root@ ;transport=udp> Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];ftag= ;lr=on>, <sip: ;ftag= ;lr=on> Frame 5 (665 bytes on wire, 665 bytes captured) Arrival Time: May 21, :58: Time delta from previous packet: seconds Time relative to first packet: seconds IPv6 Packet from 2001:388:7000:4000:20c:29ff:fe85:39d1 to 2001:620:8:801:201:2ff:fe94:8e10 Status line: SIP/ Ringing Status-Code: 180 Via: SIP/2.0/UDP [2001:620:8:801:201:2FF:FE94:8E10];branch=z9hG4bK8db8.38ac98c6.0 Via: SIP/2.0/UDP ;branch=z9hG4bK54F09626AAF411D8AA DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag= CSeq: INVITE Call-ID: 4E5C189B-AAF4-11D8-AA DB5E32@ To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa User-Agent: KPhone/3.11 Contact: "root" <sip:root@ ;transport=udp> Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];ftag= ;lr=on>, <sip: ;ftag= ;lr=on> Frame 7 (562 bytes on wire, 562 bytes captured) Arrival Time: May 21, :58: Time delta from previous packet: seconds Time relative to first packet: seconds IPv4 Packet from to Status line: SIP/ Ringing Status-Code: 180 Via: SIP/2.0/UDP ;branch=z9hG4bK54F09626AAF411D8AA DB5E32 21/29

22 From: "ArminMac" CSeq: INVITE Call-ID: To: "Armin Brunner" User-Agent: KPhone/3.11 Contact: "root" Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];ftag= ;lr=on>, <sip: ;ftag= ;lr=on> Frame 9 (902 bytes on wire, 902 bytes captured) Arrival Time: May 21, :59: Time delta from previous packet: seconds Time relative to first packet: seconds IPv6 Packet from 2001:388:7000:4000:20c:29ff:fe85:39d1 to 2001:620:8:801:201:2ff:fe94:8e10 Status line: SIP/ OK Status-Code: 200 Via: SIP/2.0/UDP [2001:620:8:801:201:2FF:FE94:8E10];branch=z9hG4bK8db8.38ac98c6.0 Via: SIP/2.0/UDP ;branch=z9hG4bK54F09626AAF411D8AA DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag= CSeq: INVITE Content-Type: application/sdp Call-ID: 4E5C189B-AAF4-11D8-AA DB5E32@ To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa Content-Length: 209 User-Agent: KPhone/3.11 Contact: "root" <sip:root@ ;transport=udp> Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];ftag= ;lr=on>, <sip: ;ftag= ;lr=on> Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): username 0 0 IN IP6 2001:388:7000:4000:20c:29ff:fe85:39d1 Session Name (s): The Funky Flow Connection Information (c): IN IP6 2001:388:7000:4000:20c:29ff:fe85:39d1 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 1062 RTP/AVP 0 3 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:3 GSM/8000 Frame 10 (795 bytes on wire, 795 bytes captured) Arrival Time: May 21, :59: Time delta from previous packet: seconds Time relative to first packet: seconds IPv4 Packet from to Status line: SIP/ OK Status-Code: 200 Via: SIP/2.0/UDP ;branch=z9hG4bK54F09626AAF411D8AA DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag= CSeq: INVITE Content-Type: application/sdp Call-ID: 4E5C189B-AAF4-11D8-AA DB5E32@ To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa Content-Length: 205 User-Agent: KPhone/3.11 Contact: "root" <sip:root@ ;transport=udp> Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];ftag= ;lr=on>, <sip: ;ftag= ;lr=on> Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): username 0 0 IN IP6 2001:388:7000:4000:20c:29ff:fe85:39d1 Session Name (s): The Funky Flow Connection Information (c): IN IP Time Description, active time (t): 0 0 Media Description, name and address (m): audio RTP/AVP 0 3 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): nortpproxy:yes 22/29