Interoperability between IPv4 and IPv6 SIP User Agents Armin Brunner Head Communication Services Swiss Federal Institute of Technology Zürich armin.brunner@id.ethz.ch 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, http://www.iptel.org/ser/) 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 http://www.voip-info.org/wiki-nat+and+voip). 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 http://voip.internet2.edu/sip.edu/ ) proposing SER on Linux 1/29
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 http://www.cs.columbia.edu/sip/. There are several good introductions and tutorials available on the web. I found the SIP introduction from Jan Janak very useful (http://www.iptel.org/ser/doc/sip_intro/sip_introduction.html). 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
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 13. 3. 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
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 http://www.linux.ericsson.ca/ipv6/csa2003.pdf. 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? (http://www.fokus.fraunhofer.de/research/cc/mobis/publ/sisa0301:sip.pdf). 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
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. 1000 parallel translated voice streams should be more than enough for an organization with 100 000+ 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
on http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/ or (better) with cvs itself (see http://www.iptel.org/ser/cvs/ ): 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 0.8.13-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: 129.132.99.126 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
# 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=129.132.99.126 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
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="129.132.99.126" 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
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 /129.132.99.126-6 2001: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
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, 129.132.99.126 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 22222. 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 http://www.xten.com - SJphone ver. 1.30.229b from http://www.sjlabs.com - Windows Messanger ver 5.0.0482 from http://www.microsoft.com IPv4 on MacOS X 10.3.4: - X-lite ver. 2.0 rel.1103a from http://www.xten.com - SJphone ver. 1.10.222b from http://www.sjlabs.com IPv4 on Linux (RedHat 9 and SuSE 9): - Kphone 4.0 from http://www.wirlab.net/kphone - SJphone ver. 1.10.222b from http://www.sjlabs.com IPv4 HW SIP Phone - Cisco 7960 with Firmware Ver. 3.6.3 IPv6 on Linux - Kphone 3.11-ipv6 from http://www.iptel.org/products/kphone 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 http://www.linphone.org/linphone.php Sip-communicator from http://www.sip-communicator.org Vocal Sipset from http://www.vovida.org resiprocate from http://resiprocate.sourceforge.net BonPhone 0.8.9d from http://www.iptel.org/products/bonephone 10/29
6.1 Testresults 6.1.1 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. 6.1.2 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. 6.1.3 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
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
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 (202.6.112.23 = sip:1@boostie.6dns.org and 202.6.112.17 = sip:2@boostie.6dns.org) and the SIP proxy in Switzerland (129.132.99.126 = 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. 202.6.112.23 129.132.99.126 202.6.112.17 <Call><PFrame><Time> F1 INVITE (sdp) >----------------------------> 1 PF:1 10:09:27.8458 Trying 100 F2 <----------------------------< 1 PF:2 10:09:28.2218 F3 INVITE (sdp) >----------------------------> 1 PF:3 10:09:28.2316 Trying 100 F4 <----------------------------< 1 PF:4 10:09:28.2498 Ringing 180 F5 <----------------------------< 1 PF:5 10:09:28.5266 Ringing 180 F6 <----------------------------< 1 PF:6 10:09:28.9005 (sdp) OK 200 F7 <----------------------------< 1 PF:7 10:09:30.2582 (sdp) OK 200 F8 <----------------------------< 1 PF:8 10:09:30.6323 F10 ACK >----------------------------> 1 PF:10 10:09:30.7825 F13 ACK >----------------------------> 1 PF:13 10:09:31.1658 SIP Session established. RTP Media Connection directly between 202.6.112.23 and 202.6.112.17 >-----------------------------------------------------------> <-----------------------------------------------------------< BYE F15 <----------------------------< 1 PF:15 10:09:33.3131 BYE F16 <----------------------------< 1 PF:16 10:09:33.6868 F17 200 Ok >----------------------------> 1 PF:17 10:09:33.7022 BYE F18 <----------------------------< 1 PF:18 10:09:33.8104 BYE F19 <----------------------------< 1 PF:19 10:09:33.9692 F20 200 Ok >----------------------------> 1 PF:20 10:09:34.0852 F21 200 Ok >----------------------------> 1 PF:21 10:09:34.1930 13/29
============== SIP MESSAGE 1 202.6.112.23:5060() -> 129.132.99.126:5060() UDP Frame 1 21/May/04 10:09:27.8458 TimeFromPreviousSipFrame=0.0000 TimeFromStart=0.0000 INVITE sip:2@boostie.6dns.org SIP/2.0 Via: SIP/2.0/UDP 202.6.112.23:5060;rport;branch=z9hG4bKE3661569AACB11D8966C000393DB5E32 From: ArminMac <sip:1@boostie.6dns.org>;tag=1545589791 To: <sip:2@boostie.6dns.org> CSeq: 35575 INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1103a Content-Length: 239 v=0 o=1 338558193 338558480 IN IP4 202.6.112.23 s=x-lite c=in IP4 202.6.112.23 t=0 0 m=audio 8000 RTP/AVP 0 8 3 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 ============== SIP MESSAGE 2 129.132.99.126:5060() -> 202.6.112.23:5060() UDP Frame 2 21/May/04 10:09:28.2218 TimeFromPreviousSipFrame=0.3760 TimeFromStart=0.3760 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 202.6.112.23:5060;rport=5060;branch=z9hG4bKE3661569AACB11D8966C000393DB5E32 From: ArminMac <sip:1@boostie.6dns.org>;tag=1545589791 To: <sip:2@boostie.6dns.org> CSeq: 35575 INVITE Server: Sip EXpress router (0.8.13-dev-28 (i386/linux)) Warning: 392 129.132.99.126:5060 "Noisy feedback tells: pid=25476 req_src_ip=202.6.112.23 req_src_port=5060 in_uri=sip:2@boostie.6dns.org out_uri=sip:2@202.6.112.17:5060 via_cnt==1" ============== SIP MESSAGE 3 129.132.99.126:5060() -> 202.6.112.17:5060() UDP Frame 3 21/May/04 10:09:28.2316 TimeFromPreviousSipFrame=0.0098 TimeFromStart=0.3858 INVITE sip:2@202.6.112.17:5060 SIP/2.0 Record-Route: <sip:129.132.99.126;ftag=1545589791;lr=on> Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bK491a.380ec8c1.0 Via: SIP/2.0/UDP 202.6.112.23:5060;rport=5060;branch=z9hG4bKE3661569AACB11D8966C000393DB5E32 From: ArminMac <sip:1@boostie.6dns.org>;tag=1545589791 To: <sip:2@boostie.6dns.org> CSeq: 35575 INVITE Max-Forwards: 69 Content-Type: application/sdp User-Agent: X-Lite release 1103a Content-Length: 239 v=0 o=1 338558193 338558480 IN IP4 202.6.112.23 s=x-lite c=in IP4 202.6.112.23 t=0 0 m=audio 8000 RTP/AVP 0 8 3 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 ============== 14/29
SIP MESSAGE 4 202.6.112.17:5060() -> 129.132.99.126:5060() UDP Frame 4 21/May/04 10:09:28.2498 TimeFromPreviousSipFrame=0.0182 TimeFromStart=0.4040 SIP/2.0 100 Trying CSeq: 35575 INVITE From: <sip:1@boostie.6dns.org>;tag=1545589791 To: "Armin Brunner"<sip:2@boostie.6dns.org>;tag=235293864 Server: SJLabs-SJphone/1.30.229b Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bK491a.380ec8c1.0,SIP/2.0/UDP 202.6.112.23:5060;branch=z9hG4bKE3661569AACB11D8966C000393DB5E32;rport=5060 ============== SIP MESSAGE 5 202.6.112.17:5060() -> 129.132.99.126:5060() UDP Frame 5 21/May/04 10:09:28.5266 TimeFromPreviousSipFrame=0.2768 TimeFromStart=0.6808 SIP/2.0 180 Ringing Contact: <sip:2@202.6.112.17:5060> CSeq: 35575 INVITE From: <sip:1@boostie.6dns.org>;tag=1545589791 Record-Route: <sip:129.132.99.126;ftag=1545589791;lr=on> To: "Armin Brunner"<sip:2@boostie.6dns.org>;tag=235293864 Server: SJLabs-SJphone/1.30.229b Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bK491a.380ec8c1.0,SIP/2.0/UDP 202.6.112.23:5060;branch=z9hG4bKE3661569AACB11D8966C000393DB5E32;rport=5060 ============== SIP MESSAGE 6 129.132.99.126:5060() -> 202.6.112.23:5060() UDP Frame 6 21/May/04 10:09:28.9005 TimeFromPreviousSipFrame=0.3740 TimeFromStart=1.0548 SIP/2.0 180 Ringing Contact: <sip:2@202.6.112.17:5060> CSeq: 35575 INVITE From: <sip:1@boostie.6dns.org>;tag=1545589791 Record-Route: <sip:129.132.99.126;ftag=1545589791;lr=on> To: "Armin Brunner"<sip:2@boostie.6dns.org>;tag=235293864 Server: SJLabs-SJphone/1.30.229b Via: SIP/2.0/UDP 202.6.112.23:5060;branch=z9hG4bKE3661569AACB11D8966C000393DB5E32;rport=5060 ============== SIP MESSAGE 7 202.6.112.17:5060() -> 129.132.99.126:5060() UDP Frame 7 21/May/04 10:09:30.2582 TimeFromPreviousSipFrame=1.3576 TimeFromStart=2.4124 SIP/2.0 200 OK Content-Length: 169 Contact: <sip:2@202.6.112.17:5060> Content-Type: application/sdp CSeq: 35575 INVITE From: <sip:1@boostie.6dns.org>;tag=1545589791 Record-Route: <sip:129.132.99.126;ftag=1545589791;lr=on> To: "Armin Brunner"<sip:2@boostie.6dns.org>;tag=235293864 Server: SJLabs-SJphone/1.30.229b Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bK491a.380ec8c1.0,SIP/2.0/UDP 202.6.112.23:5060;branch=z9hG4bKE3661569AACB11D8966C000393DB5E32;rport=5060 v=0 o=- 338558194 338558481 IN IP4 202.6.112.17 s=c=in IP4 202.6.112.17 t=0 0 m=audio 16390 RTP/AVP 0 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 ============== 15/29
SIP MESSAGE 8 129.132.99.126:5060() -> 202.6.112.23:5060() UDP Frame 8 21/May/04 10:09:30.6323 TimeFromPreviousSipFrame=0.3741 TimeFromStart=2.7865 SIP/2.0 200 OK Content-Length: 169 Contact: <sip:2@202.6.112.17:5060> Content-Type: application/sdp CSeq: 35575 INVITE From: <sip:1@boostie.6dns.org>;tag=1545589791 Record-Route: <sip:129.132.99.126;ftag=1545589791;lr=on> To: "Armin Brunner"<sip:2@boostie.6dns.org>;tag=235293864 Server: SJLabs-SJphone/1.30.229b Via: SIP/2.0/UDP 202.6.112.23:5060;branch=z9hG4bKE3661569AACB11D8966C000393DB5E32;rport=5060 v=0 o=- 338558194 338558481 IN IP4 202.6.112.17 s=c=in IP4 202.6.112.17 t=0 0 m=audio 16390 RTP/AVP 0 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 ============== SIP MESSAGE 10 202.6.112.23:5060() -> 129.132.99.126:5060() UDP Frame 10 21/May/04 10:09:30.7825 TimeFromPreviousSipFrame=0.0326 TimeFromStart=2.9368 ACK sip:2@202.6.112.17:5060 SIP/2.0 Via: SIP/2.0/UDP 202.6.112.23:5060;rport;branch=z9hG4bKE366186FAACB11D8966C000393DB5E32 From: <sip:1@boostie.6dns.org>;tag=1545589791 To: "Armin Brunner" <sip:2@boostie.6dns.org>;tag=235293864 Route: <sip:129.132.99.126;ftag=1545589791;lr=on> CSeq: 35575 ACK Max-Forwards: 70 ============== SIP MESSAGE 13 129.132.99.126:5060() -> 202.6.112.17:5060() UDP Frame 13 21/May/04 10:09:31.1658 TimeFromPreviousSipFrame=0.0369 TimeFromStart=3.3200 ACK sip:2@202.6.112.17:5060 SIP/2.0 Via: SIP/2.0/UDP 129.132.99.126;branch=0 Via: SIP/2.0/UDP 202.6.112.23:5060;rport=5060;branch=z9hG4bKE366186FAACB11D8966C000393DB5E32 From: <sip:1@boostie.6dns.org>;tag=1545589791 To: "Armin Brunner" <sip:2@boostie.6dns.org>;tag=235293864 CSeq: 35575 ACK Max-Forwards: 69 ============== SIP MESSAGE 15 202.6.112.17:5060() -> 129.132.99.126:5060() UDP Frame 15 21/May/04 10:09:33.3131 TimeFromPreviousSipFrame=1.8010 TimeFromStart=5.4674 BYE sip:1@202.6.112.23:5060 SIP/2.0 Contact: <sip:2@202.6.112.17:5060> Max-Forwards: 70 CSeq: 1 BYE From: <sip:2@boostie.6dns.org>;tag=235293864 Route: <sip:129.132.99.126;ftag=1545589791;lr=on> To: <sip:1@boostie.6dns.org>;tag=1545589791 User-Agent: SJLabs-SJphone/1.30.229b Via: SIP/2.0/UDP 202.6.112.17:5060;branch=z9hG4bKca0670110131c9b140ad64db000002fb00000026 ============== 16/29
SIP MESSAGE 16 129.132.99.126:5060() -> 202.6.112.23:5060() UDP Frame 16 21/May/04 10:09:33.6868 TimeFromPreviousSipFrame=0.3737 TimeFromStart=5.8410 BYE sip:1@202.6.112.23:5060 SIP/2.0 Contact: <sip:2@202.6.112.17:5060> Max-Forwards: 69 CSeq: 1 BYE From: <sip:2@boostie.6dns.org>;tag=235293864 To: <sip:1@boostie.6dns.org>;tag=1545589791 User-Agent: SJLabs-SJphone/1.30.229b Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bKd88b.17fe1bd3.0 Via: SIP/2.0/UDP 202.6.112.17:5060;branch=z9hG4bKca0670110131c9b140ad64db000002fb00000026 ============== SIP MESSAGE 17 202.6.112.23:5060() -> 129.132.99.126:5060() UDP Frame 17 21/May/04 10:09:33.7022 TimeFromPreviousSipFrame=0.0154 TimeFromStart=5.8564 SIP/2.0 200 Ok Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bKd88b.17fe1bd3.0 Via: SIP/2.0/UDP 202.6.112.17:5060;branch=z9hG4bKca0670110131c9b140ad64db000002fb00000026 From: <sip:2@boostie.6dns.org>;tag=235293864 To: <sip:1@boostie.6dns.org>;tag=1545589791 CSeq: 1 BYE Server: X-Lite release 1103a ============== SIP MESSAGE 18 202.6.112.17:5060() -> 129.132.99.126:5060() UDP Frame 18 21/May/04 10:09:33.8104 TimeFromPreviousSipFrame=0.1083 TimeFromStart=5.9647 BYE sip:1@202.6.112.23:5060 SIP/2.0 Contact: <sip:2@202.6.112.17:5060> Max-Forwards: 70 CSeq: 1 BYE From: <sip:2@boostie.6dns.org>;tag=235293864 Route: <sip:129.132.99.126;ftag=1545589791;lr=on> To: <sip:1@boostie.6dns.org>;tag=1545589791 User-Agent: SJLabs-SJphone/1.30.229b Via: SIP/2.0/UDP 202.6.112.17:5060;branch=z9hG4bKca0670110131c9b140ad64db000002fb00000026 ============== SIP MESSAGE 19 129.132.99.126:5060() -> 202.6.112.23:5060() UDP Frame 19 21/May/04 10:09:33.9692 TimeFromPreviousSipFrame=0.1588 TimeFromStart=6.1235 BYE sip:1@202.6.112.23:5060 SIP/2.0 Contact: <sip:2@202.6.112.17:5060> Max-Forwards: 69 CSeq: 1 BYE From: <sip:2@boostie.6dns.org>;tag=235293864 To: <sip:1@boostie.6dns.org>;tag=1545589791 User-Agent: SJLabs-SJphone/1.30.229b Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bKd88b.17fe1bd3.0 Via: SIP/2.0/UDP 202.6.112.17:5060;branch=z9hG4bKca0670110131c9b140ad64db000002fb00000026 ============== SIP MESSAGE 20 129.132.99.126:5060() -> 202.6.112.17:5060() UDP Frame 20 21/May/04 10:09:34.0852 TimeFromPreviousSipFrame=0.1159 TimeFromStart=6.2394 SIP/2.0 200 Ok Via: SIP/2.0/UDP 202.6.112.17:5060;branch=z9hG4bKca0670110131c9b140ad64db000002fb00000026 From: <sip:2@boostie.6dns.org>;tag=235293864 17/29
To: <sip:1@boostie.6dns.org>;tag=1545589791 CSeq: 1 BYE Server: X-Lite release 1103a ============== SIP MESSAGE 21 129.132.99.126:5060() -> 202.6.112.17:5060() UDP Frame 21 21/May/04 10:09:34.1930 TimeFromPreviousSipFrame=0.1079 TimeFromStart=6.3473 SIP/2.0 200 Ok Via: SIP/2.0/UDP 202.6.112.17:5060;branch=z9hG4bKca0670110131c9b140ad64db000002fb00000026 From: <sip:2@boostie.6dns.org>;tag=235293864 To: <sip:1@boostie.6dns.org>;tag=1545589791 CSeq: 1 BYE Server: X-Lite release 1103a ============== ============== 18/29
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 (202.6.112.23 = 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 (129.132.99.126/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 IP4 202.6.112.23 m=audio 8000 RTP/AVP 0 8 3 101 in Frame 1 becomes in Frame 3 c=in IP6 2001:620:8:801:201:2ff:fe94:8e10 m=audio 35058 RTP/AVP 0 8 3 101 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 IP4 129.132.99.126 m=audio 35068 RTP/AVP 0 3 These two changes make sure both UA s are connecting the rtpproxy running on 129.132.99.126/2001:620:8:801:201:2ff:fe94:8e10. Frames 12, 14, 15 are wrong (IPv4 instead of IPv6). See chapter 6.1.3 for an explanation. 202.6.112.23 129.132.99.126 (202.6.112.22) 2001:620:8:801:201:2ff:fe94:8e10 2001: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 129.132.99.126/2001:620:8:801:201:2ff:fe94:8e10 (IPv4 RTP between 202.6.112.23 and 129.132.99.126 ; 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
Frame 1 (716 bytes on wire, 716 bytes captured) Arrival Time: May 21, 2004 14:58:58.353122000 Time delta from previous packet: 2.831357000 seconds Time relative to first packet: 2.831357000 seconds IPv4 Packet from 202.6.112.23 to 129.132.99.126 Request line: INVITE sip:6@boostie.6dns.org SIP/2.0 Method: INVITE Via: SIP/2.0/UDP 202.6.112.23:5060;rport;branch=z9hG4bK54F09626AAF411D8AA78000393DB5E32 From: ArminMac <sip:1@boostie.6dns.org>;tag=120738486 To: <sip:6@boostie.6dns.org> Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 CSeq: 16833 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): 1 355928974 355929362 IN IP4 202.6.112.23 Session Name (s): X-Lite Connection Information (c): IN IP4 202.6.112.23 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 8000 RTP/AVP 0 8 3 101 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:101 0-15 Frame 2 (658 bytes on wire, 658 bytes captured) Arrival Time: May 21, 2004 14:58:58.728560000 Time delta from previous packet: 0.375438000 seconds Time relative to first packet: 3.206795000 seconds IPv4 Packet from 129.132.99.126 to 202.6.112.23 Status line: SIP/2.0 100 trying -- your call is important to us Status-Code: 100 Via: SIP/2.0/UDP 202.6.112.23:5060;rport=5060;branch=z9hG4bK54F09626AAF411D8AA78000393DB5E32 From: ArminMac <sip:1@boostie.6dns.org>;tag=120738486 To: <sip:6@boostie.6dns.org> Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 CSeq: 16833 INVITE Server: Sip EXpress router (0.8.13-dev-28 (i386/linux)) Warning: 392 129.132.99.126:5060 "Noisy feedback tells: pid=27805 req_src_ip=202.6.112.23 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, 2004 14:58:58.772135000 Time delta from previous packet: 0.043575000 seconds Time relative to first packet: 3.250370000 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=120738486;lr=on> Record-Route: <sip:129.132.99.126;r2=on;ftag=120738486;lr=on> Via: SIP/2.0/UDP [2001:620:8:801:201:2FF:FE94:8E10];branch=z9hG4bK8db8.38ac98c6.0 Via: SIP/2.0/UDP 202.6.112.23:5060;rport=5060;branch=z9hG4bK54F09626AAF411D8AA78000393DB5E32 From: ArminMac <sip:1@boostie.6dns.org>;tag=120738486 To: <sip:6@boostie.6dns.org> 20/29
Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 CSeq: 16833 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): 1 355928974 355929362 IN IP4 202.6.112.23 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 35058 RTP/AVP 0 8 3 101 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:101 0-15 Media Attribute (a): nortpproxy:yes Frame 4 (664 bytes on wire, 664 bytes captured) Arrival Time: May 21, 2004 14:58:58.802409000 Time delta from previous packet: 0.030274000 seconds Time relative to first packet: 3.280644000 seconds IPv6 Packet from 2001:388:7000:4000:20c:29ff:fe85:39d1 to 2001:620:8:801:201:2ff:fe94:8e10 Status line: SIP/2.0 100 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 202.6.112.23;branch=z9hG4bK54F09626AAF411D8AA78000393DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag=120738486 CSeq: 16833 INVITE Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa User-Agent: KPhone/3.11 Contact: "root" <sip:root@202.6.112.22;transport=udp> Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];ftag=120738486;lr=on>, <sip:129.132.99.126;ftag=120738486;lr=on> Frame 5 (665 bytes on wire, 665 bytes captured) Arrival Time: May 21, 2004 14:58:58.806700000 Time delta from previous packet: 0.004291000 seconds Time relative to first packet: 3.284935000 seconds IPv6 Packet from 2001:388:7000:4000:20c:29ff:fe85:39d1 to 2001:620:8:801:201:2ff:fe94:8e10 Status line: SIP/2.0 180 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 202.6.112.23;branch=z9hG4bK54F09626AAF411D8AA78000393DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag=120738486 CSeq: 16833 INVITE Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa User-Agent: KPhone/3.11 Contact: "root" <sip:root@202.6.112.22;transport=udp> Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];ftag=120738486;lr=on>, <sip:129.132.99.126;ftag=120738486;lr=on> Frame 7 (562 bytes on wire, 562 bytes captured) Arrival Time: May 21, 2004 14:58:59.182455000 Time delta from previous packet: 0.110986000 seconds Time relative to first packet: 3.660690000 seconds IPv4 Packet from 129.132.99.126 to 202.6.112.23 Status line: SIP/2.0 180 Ringing Status-Code: 180 Via: SIP/2.0/UDP 202.6.112.23;branch=z9hG4bK54F09626AAF411D8AA78000393DB5E32 21/29
From: "ArminMac" <sip:1@boostie.6dns.org>;tag=120738486 CSeq: 16833 INVITE Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa User-Agent: KPhone/3.11 Contact: "root" <sip:root@202.6.112.22;transport=udp> Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];ftag=120738486;lr=on>, <sip:129.132.99.126;ftag=120738486;lr=on> Frame 9 (902 bytes on wire, 902 bytes captured) Arrival Time: May 21, 2004 14:59:02.449250000 Time delta from previous packet: 3.038141000 seconds Time relative to first packet: 6.927485000 seconds IPv6 Packet from 2001:388:7000:4000:20c:29ff:fe85:39d1 to 2001:620:8:801:201:2ff:fe94:8e10 Status line: SIP/2.0 200 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 202.6.112.23;branch=z9hG4bK54F09626AAF411D8AA78000393DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag=120738486 CSeq: 16833 INVITE Content-Type: application/sdp Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa Content-Length: 209 User-Agent: KPhone/3.11 Contact: "root" <sip:root@202.6.112.22;transport=udp> Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];ftag=120738486;lr=on>, <sip:129.132.99.126;ftag=120738486;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, 2004 14:59:02.826687000 Time delta from previous packet: 0.377437000 seconds Time relative to first packet: 7.304922000 seconds IPv4 Packet from 129.132.99.126 to 202.6.112.23 Status line: SIP/2.0 200 OK Status-Code: 200 Via: SIP/2.0/UDP 202.6.112.23;branch=z9hG4bK54F09626AAF411D8AA78000393DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag=120738486 CSeq: 16833 INVITE Content-Type: application/sdp Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa Content-Length: 205 User-Agent: KPhone/3.11 Contact: "root" <sip:root@202.6.112.22;transport=udp> Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];ftag=120738486;lr=on>, <sip:129.132.99.126;ftag=120738486;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 IP4 129.132.99.126 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 35068 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
Frame 11 (498 bytes on wire, 498 bytes captured) Arrival Time: May 21, 2004 14:59:02.934541000 Time delta from previous packet: 0.107854000 seconds Time relative to first packet: 7.412776000 seconds IPv4 Packet from 202.6.112.23 to 129.132.99.126 Request line: ACK sip:root@202.6.112.22;transport=udp SIP/2.0 Method: ACK Via: SIP/2.0/UDP 202.6.112.23:5060;rport;branch=z9hG4bK54F09964AAF411D8AA78000393DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag=120738486 To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa Route: <sip:129.132.99.126;ftag=120738486;lr=on> Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 CSeq: 16833 ACK Max-Forwards: 70 Frame 12 (499 bytes on wire, 499 bytes captured) Arrival Time: May 21, 2004 14:59:03.317882000 Time delta from previous packet: 0.383341000 seconds Time relative to first packet: 7.796117000 seconds IPv4 Packet from 129.132.99.126 to 202.6.112.22 Request line: ACK sip:root@202.6.112.22;transport=udp SIP/2.0 Method: ACK Via: SIP/2.0/UDP 129.132.99.126;branch=0 Via: SIP/2.0/UDP 202.6.112.23:5060;rport=5060;branch=z9hG4bK54F09964AAF411D8AA78000393DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag=120738486 To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 CSeq: 16833 ACK Max-Forwards: 69 Frame 13 (532 bytes on wire, 532 bytes captured) Arrival Time: May 21, 2004 14:59:09.496671000 Time delta from previous packet: 6.178789000 seconds Time relative to first packet: 13.974906000 seconds IPv4 Packet from 202.6.112.23 to 129.132.99.126 Request line: BYE sip:root@202.6.112.22;transport=udp SIP/2.0 Method: BYE Via: SIP/2.0/UDP 202.6.112.23:5060;rport;branch=z9hG4bK5BB56E38AAF411D8AA78000393DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag=120738486 To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa Route: <sip:129.132.99.126;ftag=120738486;lr=on> Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 CSeq: 16834 BYE Max-Forwards: 70 User-Agent: X-Lite release 1103a Frame 14 (554 bytes on wire, 554 bytes captured) Arrival Time: May 21, 2004 14:59:09.880680000 Time delta from previous packet: 0.384009000 seconds Time relative to first packet: 14.358915000 seconds IPv4 Packet from 129.132.99.126 to 202.6.112.22 Request line: BYE sip:root@202.6.112.22;transport=udp SIP/2.0 Method: BYE Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bK5db8.23a235f3.0 23/29
Via: SIP/2.0/UDP 202.6.112.23:5060;rport=5060;branch=z9hG4bK5BB56E38AAF411D8AA78000393DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag=120738486 To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 CSeq: 16834 BYE Max-Forwards: 69 User-Agent: X-Lite release 1103a Frame 15 (617 bytes on wire, 617 bytes captured) Arrival Time: May 21, 2004 14:59:09.896272000 Time delta from previous packet: 0.015592000 seconds Time relative to first packet: 14.374507000 seconds IPv4 Packet from 202.6.112.22 to 129.132.99.126 Status line: SIP/2.0 200 OK Status-Code: 200 Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bK5db8.23a235f3.0 Via: SIP/2.0/UDP 202.6.112.23;branch=z9hG4bK5BB56E38AAF411D8AA78000393DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag=120738486 CSeq: 16834 BYE Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa User-Agent: KPhone/3.11 Contact: "root" <sip:root@202.6.112.22;transport=udp> Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];ftag=120738486;lr=on>, <sip:129.132.99.126;ftag=120738486;lr=on> Frame 18 (554 bytes on wire, 554 bytes captured) Arrival Time: May 21, 2004 14:59:10.270417000 Time delta from previous packet: 0.044805000 seconds Time relative to first packet: 14.748652000 seconds IPv4 Packet from 129.132.99.126 to 202.6.112.23 Status line: SIP/2.0 200 OK Status-Code: 200 Via: SIP/2.0/UDP 202.6.112.23;branch=z9hG4bK5BB56E38AAF411D8AA78000393DB5E32 From: "ArminMac" <sip:1@boostie.6dns.org>;tag=120738486 CSeq: 16834 BYE Call-ID: 4E5C189B-AAF4-11D8-AA78-000393DB5E32@202.6.112.23 To: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=7a7e81aa User-Agent: KPhone/3.11 Contact: "root" <sip:root@202.6.112.22;transport=udp> Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];ftag=120738486;lr=on>, <sip:129.132.99.126;ftag=120738486;lr=on> 24/29
7.3 Trace of a translated SIP-Session (6 to 1, hang-up from 6) This is a trace of a translated session with a nathelper/rtpproxy between two UA s at AARnet, Australia (202.6.112.23 = 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 (129.132.99.126/2001:620:8:801:201:2ff:fe94:8e10 = boostie.6dns.org). The SDP headers in Frame 1/2 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 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 IP6 2001:388:7000:4000:20c:29ff:fe85:39d1 m=audio 1088 RTP/AVP 0 97 3 in Frame 1 becomes in Frame 3 c=in IP4 129.132.99.126 m=audio 35046 RTP/AVP 0 97 3 and c=in IP4 202.6.112.23 m=audio 8000 in Frame 9 becomes in Frame 10 RTP/AVP 0 8 3 101 c=in IP6 2001:620:8:801:201:2ff:fe94:8e10 m=audio 35048 RTP/AVP 0 8 3 101 These two changes make sure both UA s are connecting to the rtpproxy running on 129.132.99.126/2001:620:8:801:201:2ff:fe94:8e10. Frames 9, 10, 11 are wrong (IPv4 instead of IPv6 and direct instead through proxy). See chapter 6.1.3 for an explanation. 202.6.112.23 129.132.99.126 (202.6.112.22) 2001:620:8:801:201:2ff:fe94:8e10 2001:388:7000:4000:20c:29ff:fe85:39d1 <Call><PFrame> (sdp) INVITE F1 <----------------------------< 1 PF:1 (sdp) INVITE F2 <----------------------------< 1 PF:2 F3 100 Trying >----------------------------> 1 PF:3 F4 100 Trying >----------------------------> 1 PF:4 F5 180 Ringing >----------------------------> 1 PF:5 F6 180 Ringing >----------------------------> 1 PF:6 F7 200 OK (sdp) >----------------------------> 1 PF:7 F8 200 OK (sdp) >----------------------------> 1 PF:8 ACK F9 <-----------------------------------------------------------< 1 PF:9 IPv4 instead of IPv6 direct, not to proxy SIP Session established. UDP RTP Media Connection through rtpproxy at 129.132.99.126/2001:620:8:801:201:2ff:fe94:8e10 (IPv4 RTP between 202.6.112.23 and 129.132.99.126 ; 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----------< BYE F10 direct, not to proxy <-----------------------------------------------------------< 1 PF:10 IPv4 instead of IPv6 F11 OK 200 >-----------------------------------------------------------> 1 PF:11 direct, not to proxy 25/29
Frame 1 (734 bytes on wire, 734 bytes captured) Arrival Time: May 28, 2004 15:05:02.135785000 Time delta from previous packet: 0.000000000 seconds Time relative to first packet: 0.000000000 seconds IPv6 Packet from 2001:388:7000:4000:20c:29ff:fe85:39d1 to 2001:620:8:801:201:2ff:fe94:8e10 Request line: INVITE sip:1@boostie.6dns.org SIP/2.0 Method: INVITE Via: SIP/2.0/UDP [2001:388:7000:4000:20c:29ff:fe85:39d1] CSeq: 1344 INVITE To: <sip:1@boostie.6dns.org> Content-Type: application/sdp From: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=4aaebf07 Call-ID: 561964470@202.6.112.22 Subject: sip:6@boostie.6dns.org Content-Length: 234 User-Agent: KPhone/3.11 Contact: "root" <sip:root@[2001:388:7000:4000:20c:29ff:fe85:39d1];transport=udp> 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 1088 RTP/AVP 0 97 3 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:97 ilbc/8000 Frame 2 (935 bytes on wire, 935 bytes captured) Arrival Time: May 28, 2004 15:05:02.545566000 Time delta from previous packet: 0.409781000 seconds Time relative to first packet: 0.409781000 seconds IPv4 Packet from 129.132.99.126 to 202.6.112.23 Request line: INVITE sip:1@202.6.112.23:5060 SIP/2.0 Method: INVITE Max-Forwards: 10 Record-Route: <sip:129.132.99.126;r2=on;ftag=4aaebf07;lr=on> Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];r2=on;ftag=4aaebf07;lr=on> Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bKbe2.62d99743.0 Via: SIP/2.0/UDP [2001:388:7000:4000:20c:29ff:fe85:39d1] CSeq: 1344 INVITE To: <sip:1@boostie.6dns.org> Content-Type: application/sdp From: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=4aaebf07 Call-ID: 561964470@202.6.112.22 Subject: sip:6@boostie.6dns.org Content-Length: 230 User-Agent: KPhone/3.11 Contact: "root" <sip:root@[2001:388:7000:4000:20c:29ff:fe85:39d1];transport=udp> 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 IP4 129.132.99.126 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 35046 RTP/AVP 0 97 3 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:97 ilbc/8000 Media Attribute (a): nortpproxy:yes Frame 3 (623 bytes on wire, 623 bytes captured) Arrival Time: May 28, 2004 15:05:02.603789000 Time delta from previous packet: 0.058223000 seconds Time relative to first packet: 0.468004000 seconds IPv6 Packet from 2001:620:8:801:201:2ff:fe94:8e10 to 2001:388:7000:4000:20c:29ff:fe85:39d1 Status line: SIP/2.0 100 trying -- your call is important to us 26/29
Status-Code: 100 Via: SIP/2.0/UDP [2001:388:7000:4000:20c:29ff:fe85:39d1] CSeq: 1344 INVITE To: <sip:1@boostie.6dns.org> From: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=4aaebf07 Call-ID: 561964470@202.6.112.22 Server: Sip EXpress router (0.8.13-dev-28 (i386/linux)) Warning: 392 2001:620:8:801:201:2FF:FE94:8E10:5060 "Noisy feedback tells: pid=4936 req_src_ip=2001:388:7000:4000:20c:29ff:fe85:39d1 req_src_port=5060 in_uri=sip:1@boostie.6dns.org out_uri=sip:1@202.6.112.23:5060 via_cnt==1" Frame 4 (431 bytes on wire, 431 bytes captured) Arrival Time: May 28, 2004 15:05:02.704738000 Time delta from previous packet: 0.100949000 seconds Time relative to first packet: 0.568953000 seconds IPv4 Packet from 202.6.112.23 to 129.132.99.126 Status line: SIP/2.0 100 Trying Status-Code: 100 Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bKbe2.62d99743.0 From: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=4aaebf07 To: <sip:1@boostie.6dns.org>;tag=1048536879 Record-Route: <sip:129.132.99.126;r2=on;ftag=4aaebf07;lr=on> Call-ID: 561964470@202.6.112.22 CSeq: 1344 INVITE Server: X-Lite release 1103a Frame 5 (432 bytes on wire, 432 bytes captured) Arrival Time: May 28, 2004 15:05:03.212222000 Time delta from previous packet: 0.507484000 seconds Time relative to first packet: 1.076437000 seconds IPv4 Packet from 202.6.112.23 to 129.132.99.126 Status line: SIP/2.0 180 Ringing Status-Code: 180 Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bKbe2.62d99743.0 From: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=4aaebf07 To: <sip:1@boostie.6dns.org>;tag=1048536879 Record-Route: <sip:129.132.99.126;r2=on;ftag=4aaebf07;lr=on> Call-ID: 561964470@202.6.112.22 CSeq: 1344 INVITE Server: X-Lite release 1103a Frame 6 (394 bytes on wire, 394 bytes captured) Arrival Time: May 28, 2004 15:05:03.642311000 Time delta from previous packet: 0.430089000 seconds Time relative to first packet: 1.506526000 seconds IPv6 Packet from 2001:620:8:801:201:2ff:fe94:8e10 to 2001:388:7000:4000:20c:29ff:fe85:39d1 Status line: SIP/2.0 180 Ringing Status-Code: 180 From: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=4aaebf07 To: <sip:1@boostie.6dns.org>;tag=1048536879 Record-Route: <sip:129.132.99.126;r2=on;ftag=4aaebf07;lr=on> Call-ID: 561964470@202.6.112.22 CSeq: 1344 INVITE Server: X-Lite release 1103a Frame 7 (697 bytes on wire, 697 bytes captured) 27/29
Arrival Time: May 28, 2004 15:05:05.798176000 Time delta from previous packet: 2.155865000 seconds Time relative to first packet: 3.662391000 seconds IPv4 Packet from 202.6.112.23 to 129.132.99.126 Status line: SIP/2.0 200 Ok Status-Code: 200 Via: SIP/2.0/UDP 129.132.99.126;branch=z9hG4bKbe2.62d99743.0 From: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=4aaebf07 To: <sip:1@boostie.6dns.org>;tag=1048536879 Record-Route: <sip:129.132.99.126;r2=on;ftag=4aaebf07;lr=on> Call-ID: 561964470@202.6.112.22 CSeq: 1344 INVITE Content-Type: application/sdp Server: X-Lite release 1103a Content-Length: 237 Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): 1 42602012 42605259 IN IP4 202.6.112.23 Session Name (s): X-Lite Connection Information (c): IN IP4 202.6.112.23 Time Description, active time (t): 0 0 Media Description, name and address (m): audio 8000 RTP/AVP 0 8 3 101 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:101 0-15 Frame 8 (698 bytes on wire, 698 bytes captured) Arrival Time: May 28, 2004 15:05:06.219088000 Time delta from previous packet: 0.420912000 seconds Time relative to first packet: 4.083303000 IPv6 Packet from 2001:620:8:801:201:2ff:fe94:8e10 to 2001:388:7000:4000:20c:29ff:fe85:39d1 Status line: SIP/2.0 200 Ok Status-Code: 200 From: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=4aaebf07 To: <sip:1@boostie.6dns.org>;tag=1048536879 Record-Route: <sip:129.132.99.126;r2=on;ftag=4aaebf07;lr=on> Call-ID: 561964470@202.6.112.22 CSeq: 1344 INVITE Content-Type: application/sdp Server: X-Lite release 1103a Content-Length: 276 Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): 1 42602012 42605259 IN IP4 202.6.112.23 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 35048 RTP/AVP 0 8 3 101 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:101 0-15 Media Attribute (a): nortpproxy:yes Frame 9 (419 bytes on wire, 419 bytes captured) Arrival Time: May 28, 2004 15:05:06.322953000 Time delta from previous packet: 0.103865000 seconds Time relative to first packet: 4.187168000 seconds IPv4 Packet from 202.6.112.22 to 202.6.112.23 Request line: ACK sip:1@202.6.112.23:5060 SIP/2.0 Method: ACK Via: SIP/2.0/UDP 202.6.112.22 CSeq: 1344 ACK 28/29
To: <sip:1@boostie.6dns.org>;tag=1048536879 From: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=4aaebf07 Call-ID: 561964470@202.6.112.22 Route: <sip:129.132.99.126;ftag=4aaebf07;lr=on> User-Agent: KPhone/3.11 Contact: "root" <sip:root@202.6.112.22;transport=udp> Frame 10 (419 bytes on wire, 419 bytes captured) Arrival Time: May 28, 2004 15:05:22.172469000 Time delta from previous packet: 15.849516000 seconds Time relative to first packet: 20.036684000 seconds IPv4 Packet from 202.6.112.22 to 202.6.112.23 Request line: BYE sip:1@202.6.112.23:5060 SIP/2.0 Method: BYE Via: SIP/2.0/UDP 202.6.112.22 CSeq: 1345 BYE To: <sip:1@boostie.6dns.org>;tag=1048536879 From: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=4aaebf07 Call-ID: 561964470@202.6.112.22 Route: <sip:129.132.99.126;ftag=4aaebf07;lr=on> User-Agent: KPhone/3.11 Contact: "root" <sip:root@202.6.112.22;transport=udp> Frame 11 (331 bytes on wire, 331 bytes captured) Arrival Time: May 28, 2004 15:05:22.187573000 Time delta from previous packet: 0.015104000 seconds Time relative to first packet: 20.051788000 seconds IPv4 Packet from 202.6.112.23 to Dst Addr: 202.6.112.22 Status line: SIP/2.0 200 Ok Status-Code: 200 Via: SIP/2.0/UDP 202.6.112.22 From: "Armin Brunner" <sip:6@boostie.6dns.org>;tag=4aaebf07 To: <sip:1@boostie.6dns.org>;tag=1048536879 Call-ID: 561964470@202.6.112.22 CSeq: 1345 BYE Server: X-Lite release 1103a 29/29