GB2443238A

GB2443238A - Maintaining accessibility for SIP clients behind NAT firewalls using intermediary proxy, UDP/TCP conversion and keep alive messages

Info

Publication number: GB2443238A
Application number: GB0620349A
Authority: GB
Inventors: James Holden; Adam Beaumont
Priority date: 2006-10-16
Filing date: 2006-10-16
Publication date: 2008-04-30
Also published as: GB0620349D0

Abstract

The SIP protocol typically uses UDP in communication and it can be problematic maintaining associations in some NAT firewalls for channels using this protocol. As a result an SIP client being used for VoIP cannot receive incoming calls. The invention proposes the use of an intermediary located outside the firewall. This translates messages from the SIP registration server from UDP to TCP for sending through the firewall to the client, and vice versa. The TCP NAT translation binding is kept alive with periodic messages sent by the intermediary. The intermediary may also reformat SIP messages so that clients and servers using different formats can communicate.

Description

Protocol and Syntax Converting Session Border Controller for

Maintaining Session initiation protocol Voice over IP Telephony Data Sessions.

Background

Nose -,see De/Initions for clarification of germs Voice over lP telephony (VoW) is a relatively new technology in the public arena. A common application of VoIP is for allowing peer-to-peer communication entirely over IP without any access or egress to or from existing telecoms infrastructure (such as the PSTN or GSM networks), with the consequences of saving the costs associated with such access and egress and other benefits relating to ease of use and flexibility of routing.

Voice over IP traffic can use several different protocols. One of the most common protocols is SIP (Session Initiation Protocol).

Using the SIP protocol*, a typical scenario would be that a SIP telephony handset ("SIP Client") is connected to the internet and would register with a remote registration server. This server tracks the IP endpoint of the client (Ic the IP address and PORT to which to direct any SIP traffic). When one SIP Client wishes to communicate with a second client, the registration server can connect the two endpoints together. This is initiated by a SIP INVITE session.

*SIP protocol -see RFC 3261 (www.ietf.org) One of the most readily available open-source PBX architectures capable of handling SIP registrations and call invites is a "sip proxy" solution known as asterisk from www.asterisk.org. This well known architecture receives and sends SIP requests using UDP (user datagram protocol) only. Such architectures are often used to provide remote VoIP services.

The asterisk sip registration server (and other similar architectures) allow remote SIP users ("Subscribers") to register with the server and define their IP address and Port ("Endpoint") which is tracked in a database. When one Subscriber (ie a SIP Client) attempts to call another, a SIP ENVITE request is sent to the receiving party to initiate the negotiation of a call. This INVITE request is sent from the asterisk sip registration server (or other similar server) to the IP Endpoint (IP address and PORT) of the remote SIP Client.

*:*::* Many users of VoW services use SIP Clients which reside at the end of ADSL lines whereas the SIP registration server itself may be hosted remotely on a different IP network. Usually, ADSL lines use a router device which conventionally has an external real IP address (eg an lP * ** address assigned by RIPE or ARIN), whereas the inside network has a number of private ip : * addresses-such as a 192.l68.O.O/24** network (in conventional network notation). Traffic passes across the ADSL router by a process known as network address translation, NAT.

* * **refer to IETF (www.ietf.org) RFC 1918 * ** S.. * *

Many ADSL (and other) routers, have robust network address translation capability for TCP data, reliably mapping data from external IP addresses and ports to the corresponding port and IP address on the inside of the network and vice versa. The network address translation rules "XLATES" which map data source and destination IP address and ports are temporary rules which expire after a finite time. Many ADSL routers have less robust capabilities for handling or maintaining NAT translations with UDP data.

If the SIP endpoint (the lP address and TCP port of the SIP Client) is lost, due to the XLATE expiring in the ADSL's volatile routing table, it may not be possible to make an inbound call to the corresponding SIP client, because there is no inbound path defined in order to route the TCP and UDP traffic. This is shown schematically in Figure Ia, where a NAT translation rule XLATE" exists and Figure I b, where the data cannot reach the SiP device, because the NAT translation rule "XLATE" has expired (ie does not exist at that moment in time when required).

Devices which help to augment or track associations between networks with the purpose of maintaining sessions are commonly referred to as Session Border Controllers. The Invention herein is a process which may be equated to a method of Session Border Control. Figure 2 shows the schematic positioning of the Session Border Controller in a typical IP network, such that data is passed between the SIP Client (I) to the SBC (2) and the data is then manipulated and sent to the SIP registration server (3). The converse is also true -data returned back from the SIP registration server (3) is manipulated by the SBC (2) and passed back to the SIP Client (1).

Additionally, hurdles exist such that many SIP Clients do not create SIP requests in forms which are recognised by industry standard SIP registration servers such as asterisk. This is usually a shortcoming as a result of the way the SIP protocol is invoked by the clients' software. Therefore, there are often issues with certain SIP Clients failing to function correctly with such industry standard SIP registration servers due to an incorrect or incompatible invocation of the SIP protocol. As such there is also a requirement for a device to correct and re-write such badly formed SIP requests such that they are compatible with and understood by industry standard SIP registration servers such as, but not limited to, the asterisk PBX (asterisk.org) or SIP express router (iptel.org) * S. * * . * ** S... * . * *SS S. ** * * S * .

S * * S. * S * * S.

**..*S *

Statement of Invention

A Session Border Control (SBC) process has been created which serves to alter and preserve SIP requests and SIP sessions, respectively, such that the end SIP client device will be receptive and able to respond to a SIP INVITE request, even if I) the SIP client device resides behind a NAT Router, such as an ADSL router.

2) l'he SIP client device sends incorrectly formed SIP packets or SIP packets which are incompatible with the SIP proxy being used.

Many SIP client devices have the option to select I) a SIP proxy address -the address of the server to subscribe to and to initiate SIP requests VIA and 2) an outbound proxy address -the address of a server to send outbound SIP request data VIA and to specify the type of protocol used -ie TCP or UDP.

The invention functions with devices which can specify an outbound proxy and use TCP to transport SIP requests.

The Session Border Control process functionality is achieved by a combination of components: Component I. As a result of the inability or lack of effective ability of many ADSL NAT (and other) Routers to perform satisfactory network address translation and to maintain the mapping between the source IP and port and the destination IP and port for UDP data packets, part of the function of the Session Border Control process is to convert the UDP SIP requests from the SIP proxy to TCP and thus converting connectionless (UDP) SIP packets into connection-oriented (TCP) SIP packets, which can be handled more predictably by ApSL NAT (and other) Router devices.

Component 2. In order to maintain the association or XLATE within an ADSL NAT (or other) Router, the Session Border Control process periodically sends TCP SIP NOTIFY packets to the SIP Client in order to maintain the XLATE(s) on the ADSL (or other) Router, which performs NAT, behind which the SIP Client resides. The SIP NOTIFY packets contain no payload and serve no purpose other than to act as a "heartbeat" or "keepalive" to help the ADSL (or other) Router maintain the mapping between the source IP and port of the SIP client and the destination IP and port of the SIP Session Border Controller. The Session Border Controller will also effectively discard any replies that emanate from the SIP Client as a result of responding to the keepalive SIP NOTIFY packets. S...

The use of a keepalive or heartbeat type communication using SIP NOTIFY actively maintains stateful (ie: TCP) connections to the SIP Client through the ADSL (or other) Router device whilst having the benefit of also allowing requests from stateless (ie: UDP) upstream * hosts to be injected into the endpoint-initiated TCP connection following a SIP INVITE dialogue. Thus, (.JDP (RTP type) (Voice or Media) streams (eg those proxied by the Session Border Controller or SIP Registration server or other media proxy as part of an initiated voice conversation) can be mapped across the TCP endpoint associations kept alive and residing * ** within the ADSL (or other) Router.

*..S*. * S

Introduction to Drawings

Figure Ia, When a valid TCP translation rule exists on a router device (3) -eg an ADSL NAT (or other) Router, the SBC (5) would have an inbound route across the internet or other IP medium (4) into the router (3). The router would be able to map the inbound TCP requests which would be addressed via the outside (Real, eg, RIPE or ARIN or other numbering registry assigned) IP address of the router to the relevant IP Endpoint on the SIP Client behind the router (I), transported, in this case, (but not necessarily in all cases) via a Wireless connection. Once the TCP translation has been established and is kept alive by periodic SIP NOTIFY requests, it would be possible for inbound TCP SIP INVITE requests to reach the SIP Endpoint (I) and thus possible for inbound calling to take place. Figure Ib, ilthere is iio translation rule kept alive on the router device (3), any inbound TCP SIP INVITE would fail due to there being no mapping between the real (eg RIPE or ARIN or other numbering registry assigned) IP address on the outside of the router and the private IP address of the SIP endpoint. The inbound call would fail. * ** * * I * S. S... * S **S. I. *S S. * * S

S *S.

S * S. * S 5 * SS

S

* SSS5I S 5 Component 3. In order to ensure that the SIP requests from non-compliant or non-compatible client devices are understood by the SIP (eg asterisk) registration server, the SIP header can be re-written such that the SIP request follows the expected format of the SIP (eg asterisk) registration server, thus compatibilising a previously incompatible SIP client with the SIP proxy. * S. * . . * *. S'S. * * *S*. *. S. * * * * *

S

S * ** * * S * S.

*SS.S. * .

Advantages By converting the SIP requests I SIP headers as created by readily available SIP proxies such as asterisk from UDP to TCP this creates a much higher level of compatibility the data flows with ADSL NAT (and other) Routers. This means that there is a greater chance of VoIP users with a SIP client on a NAT network being able to make outbound and inbound calls.

Existing SIP Registration servers such as Asterisk do actually send UDP SIP OPTIONS commands as keepalives, but many SIP Clients (such as the nokia E Series handsets -eg e60, e6l, e70) do not recognise these and as a result cannot be kept "alive" behind a NAT connection by existing registration servers. In addition, a UDP keepalive cannot always maintain a translation in a NAT router between the SIP Client and the SIP registration server or other device.

By using a different kind of KEEPALIVE or heartbeat (utilising a TCP SIP NOTIFY command), this helps augment the user experience of a SIP based VoIP service if the user is behind an ADSL NAT (or other) Router. This is because of a route or translation being kept alive on the subscribers ADSL NAT (or other) router, helping to ensure that there is always an inbound path for TCP and UDP traffic which will ensure that it is possible to make an inbound SIP call to the SIP clients IP endpoint - ie their phone will ring if it is called, whereas if there is no TCP translation or association kept alive on the ADSL NAT (or other) Router, the inbound call will fail.

Example

Wireless VoIP is starting to become a more tenable proposition. With the introduction of GSM handsets with build-in SIP clients and WiFi capability (such as the Nokia e60, e61, e70, there exists the opportunity to make VoIP calls using a mobile phone from wherever there is an accessible WiFi access point ("hotspot") by using the WiFi capability to provide IP transit capable of supporting a VoIP conversation.

However, by its very nature, mobile VoIP will rely on the maintenance of a persistent association between the remote SIP proxy and the IP endpoint of the SIP client. In order to ensure this association is robust, the utilisation of the invention herein will ensure that the (in this case mobile) SIP device can be reached by incoming calls and indeed can call other similar devices registered under similar circumstances.

* Figure 3 describes, in general terms, the data flows associated with an interaction between (in **.*. this example, but not limited to) a Nokia E-Series Mobile handset, the Session Border Controller (SBC) and the Upstream host(eg Asterisk SIP registration server), during an attempted VoIP call using either a WiFI hotspot, 3g data connection or other IP connection :. involving NAT or other address translation.

* 1) A Nokia E Series handset initiates TCP/IP connection to the SBC (via an IP connection such as a WiFi access point, 3g connection, Bluetooth connection or other IP based connection).

* *. 2) The SBC accepts the connection and adds it to a list of currently open TCP/IP connections.

3)The Nokia E Series sends a SIP REGISTER request over the TCP/IP connection to the *....: SBC. * *

4) The SBC parses the request and determines the SIP username from it. A persistent association is made linking the SIP username to the Tcp/IP connection via an entry in a local database.

5) The SBC removes the Route header.

6) The SBC adds a Record-Route header stating it's IP address and UDP port number.

7) The SBC appends the existing Via header with the IP address and TCP port on which the request was received -this is necessary to inform Asterisk that the endpoint will require the media traffic to be proxied via Asterisk or other proxy.

8) The rewritten request is sent over UDP to the upstream host.

9) When a reply is received from the upstream host, the headers are parsed for the sip username.

10) When found, the username is looked up in the already-populated table to determine which TCP/IP connect (te endpoint) to use.

11) 1'he Via header is removed so that the handset will recognise the reply as having reached it's destination.

12) The reply is sent via the pre-existing TCP/IP connection that the handset established in the first place.

An example of a typical exchange would take place as follows (no specific headers shown): Where sipsbcscrvenamrport isa typical example ofa SIP IJRI (uniform resource identifier) of the SBC sipusernameprivatc_ip_address port isa typical example ofa SIP URI (uniform resource identifier) of the SIP Client (Eg Nokia SIP Client running on nokia E60 handset).

Initial register-Handset Registers via the SBC with the SIP Registration server: Nokia -> SBC: REG I STER sip:sbcservername:port;traiisport=TCP SI P/2.0 SBC -> Upstream: REGISTER sip:sbcservername: port;transport=TCP SI P/2.0 Upstream -> SBC: SIP/2.0 100 Trying SBC -> Nokia: SIP/2.0 100 Trying Upstream -> SBC: SIP/2.0 401 Unauthorized SBC -> Nokia: SIP/2.0 401 Unauthorized Nokia -> SBC: REGISTER sip:sbcservername:port;transport=TCP SIP/2.0 (this time with authentication information) SBC -> Upstream: REGISTER sip:sbcservername:port;transport=TCP SIP/2.0 (this time with authentication information) Upstream -> SBC: SIPI2.0 100 Trying SBC -> Nokia: SIP/2.0 100 Trying Upstream -> SBC: SIP/2.0 200 OK SBC -> Nokia: SIP/2.0 200 OK *:*::* Incoming call: Upstream -> SBC: INV ITE sip:usernameprivatejp_address;transport=TCP SI P/2.0 SBC -> Nokia: IN V ITE sip: username@privateip_address;transport=TCP SI P/2.0 Nokia -> SBC: SIP/2.0 100 Trying : * SBC -> Upstream: SIP/2.0 100 Trying * Nokia -> SBC: SIP/2.0 180 Ringing *** * SBC -> Upstream: SIP/2.0 180 Ringing (call is answered on Nokia) Nokia -> SBC: SIP/2.0 200 OK * SBC -> Upstream: SIP/2.0 200 OK * * Upstream -> SBC: AC K sip:username@private_ip_address;transport=TC P SI P/2.0 SBC -> Nokia. ACK sip: usemame@private.Jp_address;transport=TC P SI P/2.0 Call is now in progress Note -a full example of a real SIP dialogue between two SiP Client devices and a SIP Registration Server, Via the SBC is shown in Appendix 1 * S. * * S * S. * * **S S. *S * S * * S

S *.. * *. * * . * S.

S

*5**SS * S

Detailed Description

Definitions SlP EndpoinC. Endpoint" -any IP based device capable of acting as a SIP client eg a Nokia E-series phone (eg e60, c61. e70) "SBC -Session border controller -the intermediate device between the SIP client and the SIP registration server Upstream -SIP registration server -eg Asterisk or other registration server.

The detailed description below describes the interrelation of the SIP Endpoint (for example, but not limited to the "Nokia E-Series handset" as represented in Figure (3) ) and the SBC and the SIP proxy (for example but not limited to Asterisk SIP PBX).

The description of the process takes the form of a detailed but generic data flow between the Endpoint, the SBC and the Upstream.

Initial SIP connection and first request: SIP Endpoint -> SBC SIP Endpoint -> SBC: Establish TCP SIP connection SBC: Append IP address to a database of open TCP connections SIP Endpoint -> SBC: Sends SIP requests (Initially a SIP REGISTER) SBC: Parses SIP request into internal data structure (parses entire SIP request -Req uest+Headers+Body) SBC: Scans SIP request for endpoint usemame and when found, maintains mapping between TCP connections and SIP usemames (Creates a hash table to link sip usernames to the specific tcp connection it was seen on) SBC: Rewrites headers to record route so that upstream server can forward the reply back via the proxy(adds record-route header and via header showing the SBC's UDP IP and PORT so that the upstream host knows to send traffic back via the SBC) * ** SBC: Rewrites request and headers so that (any) malformed request ***e. is valid* (detects and fixes any invalid INVITE request string using information from the headers) I. *S. . . -. . . . * * * *his is of particular importance in order to compatibilise devices which have non-compliant SIP Clients such as certain Nokia devices eg (e6 I, e60, e7 I software release I.0610.02.05) Such compatibilisation is based on inserting rules into the SBC which parse and re-map any incompatible parts of the SIP requests based on known inconsistencies as determined by experiment. * **

S

****** * S (0 SBC -> Upstream SBC -> Upstream: Forwards processed SIP request via UDP Upstream -> SBC Upstream -> SBC: Reply is received by Proxy (SIP reply to previous request from endpoint).

SBC: SIP username is parsed from reply (used to determine which tcp connection to send it out through) SBC: Removes routing headers from reply (the last via header) SBC -> Endpoint SBC -> Endpoint: Forwards reply via the same TCP connection that the endpoint originally established, as determined by the mapping created previously. (ie the lookup table that was populated by the first SIP request from the endpoint) Subsequent upstream initiated requests: Upstream -> SBC Upstream -> SBC: SIP request received (any sort of request -most likely an INVITE) SBC: SIP request is parsed aiid routing headers removed (because they may confuse the SIP Client (endpoint) -they would tell it to route the request instead of accepting it locally) SBC: SIP username is parsed from request SBC: SIP request/headers are rewritten to be acceptable to the device in order to compatibilise with the sip proxy.

SBC: Previously determined username->TCP connection mapping is used to determine where to forward the request to * S. * S * * S. S... * S *S 55 * . 5 * .

S S..

S * .. * S 5 * *S

S

*.SS.. * S

SBC -> Endpoint SBC..> Endpoint: The request is forwarded over the same TCP connection the endpoint established Keepalive: Keepalive is repeated periodically -for example (but not necessarily), Every 15 seconds (ie with the possibility of more or less frequent polling) for all TCP connected clients SBC: Generates SIP NOTIFY request SBC -> Endpoint: Sends SIP NOTIFY to endpoint Endpoint-SBC: SBC discards ally reply from the endpoint which if passed back to the Upstream registration server may confuse the SIP Dialogue. * ** * * S * S. S... * . **S. S. * . . * .

S * S* * S * * **

S

* .*S.. * S

Claims

Claims 1) a process which involves the control and/or modification of

data flows within a SIP dialogue by using an intermediate device running a software application which interacts with both a SIP Client(s) aiid a SIP registration server.

2) a process as per Claim (I), where a SIP Client(s) would register or interact via SIP protocol with a registration server via the intermediate device 3) a process as per Claim (2), where the intermediate device would accept TCP SIP requests from the SIP client(s) and convert the TCP based SIP requests from the SIP Client(s) into UDP requests which would be forwarded to the SIP registration server.

4) a process as per Claim (2) where the intermediate device would convert UDP SIP requests from a SIP registration server and convert such requests to a TCP Sip equivaient and pass such requests back to a SIP Client(s).

5) a process as per Claim 2 where the intermediate device would parse and re-write any invalid or syntactically incorrect SIP requests, if required. based on pre-defined knowledge of SIP Client(s) profiles and any known defects in the SIP request syntax from those SIP Client(s) if required.

6) a process as per Claim 2 where the intermediate device would parse and re-write SIP requests based on known incompatible requests in order to ensure that the SIP requests from the SIP Client were re-written such that they were compatible with the SiP Registration server.

7) a process as per claim (2) where the intermediate device would parse and re-write SIP requests from the SIP registration server in order to ensure that the SIP requests from the SIP Registration server were re-writteii such that they were compatible with the SIP Client(s).

8) a process as per claim (2) whereby a SIP Client would register with a registration server via the intermediate device and the intermediate device would log the SIP endpoint of the SIP Client.

9) a process as per claim (8) whereby once the SIP endpoint of the SIP Client is known, the intermediate device would send TCP SIP packets consisting of SIP NOTIFY requests with * empty payload back to the SIP endpoint on a periodic basis and of a frequency sufficient to maintain a TCP network and port translation in any network address translating and/or routing devices between the intermediate device and the SIP endpoint, for example but not limited to s.'.. anADSLNAlrouter.

:.. lO)a process as per claim (9) whereby any replies from the SIP client to the intermediate * device to any TCP SIP NOTIFY requests sent for the purposes of maintaining a TCP connection are discarded and not passed on to the SIP Registration server. * *s * * * * S. *

5*5S5* Appendix I Real Example of SIP traffic passed between "Sip Client 1" -3 SBC -3 Asterisk Registration Server -3 SBC -3 "Sip Client 2" Where sbc test aqi corn is the Session Border Controller / intermediate device on IP address 194.145.190.152 SIP lest aql corn is Ihe SIP registration server (eg asterisk) on IP address 194.145.190.153 SIP cIientIsip test aql corn is a okia K-Series phone "client I" (ie SIP Client / SIP device I) residing, in this instance on a private UP address (192 16806) behind an ADSI. NA]' router at IP 19393753 sip client2sip test aqi corn is another you' SII' phone "client 2" (ie SIP Client / SIP device I) residing, in this instance on an asterisk PBX -ie at the endpoint sip:client2@194.145.190.153 In each step 01 the example, the heading signuties which component of the system the SIP dIalogue relates to and in which direction the dialogue occurs -eg "nokia -sbc" signifying a SIt' dialogue from the Nokia c-series device (eg Nokia e61) to the session border controller (SBC).

In any SIP dialogue FROM the SBC, any SIP headers/requests which are changed or added by the SBC are shown in bold and underlined. IF data which is altered or removed by the SBC before passing it to Asterisk or to a SI!' Client.

In any SIP dialogue JO the SBC, any SIP headers/requests which are to be removed by the SBC are also shown in bold and underlined.

Example I. Client I "Nokia" initiates call to Client 2 Client I "Nokia" -> SBC: INVITE sp:sbc.test.aql.com:5065;transport=TCP SIP/2.O Route: <sip:client2@sip.test.aql.com> Via: SIP/2.0/TCP 193. 93.7. 53:5060;branch=z9hG4bKppoukaljcdhc6e2dO45qle2 From: <slp:clientl@sip.test.aql.corn>;tag=ggaekalkjdhc78eao45q To: <sip:client2@siptest.aql.corn> Contact: <sip:clientl@192.168.0.6;transport=TCP> CSeq: 1349 INVITE Call-ID: 4PrGawsloIcIIM4bGFpoMCzplwdP9R Supported: sec-agree Allow: INVITE,ACK,BYE,CANCEL,REFER,NOTIFY * expires: 120 Privacy: none S's. P-Preferred-Identity: sip:clientl@sip.test.aql.com Max-Forwards: 70 :.. Content-Type: application/sdp * Accept: application/sdp :. ContentLength: 426 v=0 **:* o=Nokia-SIPUA 63329107124554125 63329107124554125 IN 1P4 193.93.7.53 s=-c=IN 1P4 193.93.7.53 t=0 0 rn=audio 16384 RTP/AVP 96 0 8 97 18 98 13 a=inactive afmtp:96 octet-a1gn=O afmtp:97 mode=30 a=frntp: 18 annexb=yes a=fmtp:98 0-15 a=rtpmap:96 AMR/8000/1 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:97 1LBC/8000/1 a=rtpmap:18 G729/8000/1 a=rtpmap: 98 tetephone-event/8000/1 a=rtpmap:13 CN/800011 SBC -> Asterisk: INVITE <sip:client2@sip.test.agl.com> SIP/2.O Record-route: <sip:194.145.190.152:5065;r2=on;lr=on> Record-route: <sip: 194.145.190. 152:5065;transporttcp;r2=on;lr=on> Via: SIP/2.0/tJDP 194.145.190.152:5065;branch=ce78dd79bc8749230d66be707420f7 Via: S1P12.O,TCP 193.93.7.53:5060;branch=z9hG4bKppoukaljcdhc6e2do45qle2;rport=38285;re ceived=193.93.7.53 From: <s1p:clientl@sip.test.aql.com>;tag=ggaeka1kdhc78ea045q To: <sip:client2@sip.test.aql.com> Contact: <sip:clientl@192. 168. 0. 6;transport=TCP>;received="sip: 193. 93.7. 53: 382 85; transport=TCP" CSeq: 1349 INVLTE Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdp9p.

Supported: sec-agree Allow: INVITE,ACK, BYE, CANCEL, REFER, NOTIFY expires: 120 Privacy: none P-Preferred-Identity: sip:clientl@sip.test.aql.com Max-Forwards: 70 Content-Type: application/sdp Accept: application/sdp Content-Length: 426 v=0 o=Nokia-SIPUA 63329107124554125 63329107124554125 IN 1P4 193.93.7.53 s-c=IN IP4 193.93.7.53 t=0 0 m=audio 16384 RTP/AVP 96 0 8 97 18 98 13 a=inactive * a=fmtp:96 octet-align=O **** * * a=fmtp:97 mode=30 a=fmtp:18 annexb=yes a=fmtp:98 0-15 a=rtpmap:96 AMR/8000/1 a=rtprnap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:97 iLBC/8000/1 * ** a=rtpmap:18 G729/8000/1 a=rtpmap: 98 telephone-event/8000/1 * a=rtpmap:13 CN/8000/1 * * Asterisk -> SBC: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 194. 145.190.152:5065;branch=ce78dd79bc8749230d66be707420f7;receivedl 94.145.190.152 Via: SIP/2.0/TCP 193.93.7.53:5060;branch=z9hG4bKppoukaljcdhc6e2d045qle2;rport=38285;re ceived=193.93.7.53 From: <sip:clientl@sip.test.aql.com>;tag=ggaekalkjdhc78eao45q To: <sip:client2@sip.test.aql.com>;tag=asl4cf5bfc Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R CSeq: 1349 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:client2@194.l45.l90.153> Proxy-Authenticate: Digest realm'"sip.test.aql.com", nonce="01b44709" Content-Length: 0 SBC -> Client I "Nokia": SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/TCP 193.93.7.53:5060;branch=z9hG4bKppoukaljcdhc6e2dO45qle2;rport=38285;re ceived=193. 93.7.53 From: <sip:clientl@sip.test.aql.com>;tag=ggaekalkjdhc78ea045q To: <sip:client2@sip.test.aql.com>;tag=asl4cf5bfc Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R CSeq: 1349 INVITE Allow: INVITE, ACM, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:client2@194.145.190.153> Proxy-Authenticate: Digest realm="sip.test.aql.corn", nonce="01b44709" Content-Length: 0 Client I "Nokia" -> SBC: ACM sip:sbc.test.aql.com:5065;transport=TCP SIP/2.0 Via: SIP/2.0/TCP 193. 93. 7. 53:5060; branch=z9hG4bKppoukaljcdhc6e2dO45qle2 Route: <sip:client2@sip.test.aql.com> From: <sip:clientl@sip.test.aql.com>;tag=ggaekalkjdhc78eaO45q To: <sip:client2@sip.test.aql.com>;tag=asl4cf5bfc Call-ID: 4PrGawsloIcIIM4bGEpoMOzplwdP9R CSeq: 1349 ACK Supported: sec-agree Max-Forwards: 70 * *. Content-Length: 0 * . . * S. S...

S... SBC -> Asterisk: ACM sip:sbc.test.aql.com:5065;transport=TCP SIP/2.0 * . Record-route: <sip:194.145.190.152:5065;r2=on;lron> * Record-route: <sip: 194.145.190. 152:5065;transport=tcp;r2=ori;lr=on> Via: SIP/2.0/UDP 194.145.190. 152:5065;branch=b82184b51aae1bba848f52b685160b * *. Via: SIP/2.0/TCP * S S * 5. 193.93.7.53:5060;branch=z9hG4bKppoukaljcdhc6e2d045qle2;rport=38285;re ceivedl93.93.7.53 * From: <sip:clientl@sip.test.aql.com>;tag=ggaekalkjdhc78eaO45q To: <sip:client2@sip.test.aql.corn>;tagasl4cf5bfc Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R CSeq: 1349 ACK Supported: sec-agree Max-Forwards: 70 Content-Length: 0 Client I "Nokia" -> SBC: INVITE sip:sbc.test.aql.com:5065;transport=TCP SIP/2.0 Route: <sip:client2@sap.test.aql.com> Via: SIP/2.0/TCP 193. 93.7. 53: 5060;branch=z9hG4bK5oqlu7nioegkj i7vit8lOlrb From: <sip:clientl@sip.test.aql.com>;tag=ggaekalkjdhc78ea045q To: <sip:client2@sip.test.aql.com> Contact: <sip:clientl@192.168.0.6;transport=TCP> CSeq: 1350 INVITE Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R Supported: sec-agree Allow: INVITE, ACM, BYE, CANCEL, REFER, NOTIFY expires: 120 Privacy: none P-Preferred-Identity: sip:clientl@sip.test.aql.com Max-Forwards: 70 Proxy-Authorization: Digest realrn="sip.test.aql.com",nonce="01b44709",algorithm=MD5,username=c1i entl",uri="sip:sbc.test.aql.com:5065;transport=TCP",response="a49f4b4 a9a5f7ffdc8fOfe76f29e5O64" Content-Type: application/sdp Accept: application/sdp Content-Length: 426 v= 0 o=Nokia-SIPUA 63329107124554125 63329107124554125 IN 1P4 193.93.7.53 s=-c=IN 1P4 193.93.7.53 t=0 0 m=audio 16384 RTP/AVP 96 0 8 97 18 98 13 a=inactive a=fmtp: 96 octet-align=0 a=fmtp:97 mode=30 a=fmtp: 18 annexb=yes a=fmtp:98 0-15 a=rtpmap: 96 AMR/8000/1 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap: 97 iLBC/8000/1 . a=rtprnap:18 G729/8000/1 * . a=rtpmap:98 telephone-event/8000/1 **** * * a=rtpmap:13 CN/8000/1 ***.

SBC -> Asterisk: *. INVITE <sip:client2@sip.test.agl.com> SIP/2.0 * Record-route: <sip:194.145.190.152:5065;r2=on;lron> Record-route: <sip: 194.145.190.152:5065;transport=tcp;r2on;lr=on> * ** * * * Via: SIP/2.0/UDP * 194.l45.190.152:5065;branchb82184b51aae1bba848f52b685160b Via: SIP/2.0/TCP 193. 93.7. 53:5060;branch=z9hG4bK5oqlu7moegkji7vit8l0lrb;rport=38285;re ceivedl93. 93.7.53 From: <sip:clientl@sip.test.aql.com>;tag=ggaekalkjdhc78ea045q To: <sip:client2@sip.test.aql.com> Contact: <sip:clientl@192.168.0. 6;transport=TCP>; received="sip: 193. 93.7.53: 382 85; transport=TCP" CSeq: 1350 INVITE Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R Supported: sec-agree Allow: INVITE,ACK, BYE, CANCEL, REFER, NOTIFY expires: 120 Privacy: none P-Preferred-Identity: sip:clientl@sip.test.aqi.com Max-Forwards: 70 Proxy-Authori zation: Digest realm="sip.test.aql.com",nonce="01b44709",algorithmMD5,usernarne"cli entl",uri="sip:sbc.test.aql.com:5065;transport=TCP",response="a49f4b4 a9a5f7ffdc8fOfe76f29e5O64" Content-Type: application/sdp Accept: application/sdp Content-Length: 426 v=0 o=Nokia-SIPUA 63329107124554125 63329107124554125 IN 1P4 193.93.7.53 5=-c=IN 1P4 193.93.7.53 t=0 0 m=audio 16384 RTP/AVP 96 0 8 97 18 98 13 a=inact ive a=fmtp: 96 octet-align=0 a=fmtp:97 mode30 a=fmtp: 18 annexb=yes a=fmtp:98 0-15 a=rtpmap:96 AMR/8000/1 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/l a=rtpmap:97 iLBC/8000/1 a=rtpmap:18 G729/8000/l a=rtpmap: 98 telephone-event/8000/1 a=rtpmap:13 CN/8000/1 Asterisk -> SBC: SIP/2.0 100 Trying Via: SIP/2.0/UDP 194.145.190.152: 5065;branch=b82184b5].aaelbba84Bf52b685l6Ob;received=1 94.145.190.152 Via: SIP/2.0/TCP 193.93.7.53:5060;branch=z9hG4bk5oqlu7moegkji7vit8lOlrb;rport=38285;re * * ceived=193.93.7.53 S...

From: <sip:clientl@sip.test.aql.com>;tag=ggaekalkjdhc78ea045q ** ** To: <sip:client2@sip.test.aql.com> * *. Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdPYR CSeq: 1350 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY * *5 Contact: <sip:client2@194.l45.190.153> Content-Length: 0 S..... * .

SBC -> Client I "Nokia": SIP/2.0 100 Trying Via: SIP/2.0/TCP 193.93.7.53:5060;branch=z9hG4bKsoqlu7moegkji7vit8l0lrb;rport=38285;re ceived=193. 93.7.53 From: <sip:clientl@sip.test.aql.com>;tag=ggaekalkjdhc78eaO45q To: <sip:client2@sip.test.aql.com> Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R CSeq: 1350 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:client2@194.145.190.153> Content-Length: 0 Asterisk -> SBC: SIP/2.0 180 Ringing Via: SIP/2.0/tJDP 194.145.190. 152:5065;branch=b82184b51aae1bba848f52b685160b;received=1 94.145.190.152 Via: SIP/2.0/TCP 193.93.7.53:5060;branch=z9hG4bK5oqlu7rnoegkji7vit8lolrb;rport=38285;re ceived=193. 93.7.53 From: <sip:clientl@sip.test.aql.com>;tag=ggaekalkjdhc78ea045q To: <sip:client2@sip.test.aql.com>;tag=as38aa8a73 Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R CSeq: 1350 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:client2@194.145.190.153> Content-Length: 0 SBC -> Client I "Nokia": SIP/2.0 180 Ringing Via: SIP/2.0/TCP 193.93.7.53: 5060;branchz9hG4bK5oqlu7moegkji7vit8l0lrb; rport=38285; re ceived=193. 93.7.53 From: <sip:clientl@sip.test.aql.com>;tag=ggaekalkjdhc78ea045q To: <sip:client2@sip.test.aql.com>;tagas38aa8a73 Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R CSeq: 1350 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:client2@194.145.l90.153> Content-Length: 0 * ** Called Party Answers **** * * **** :. Asterisk -> SBC: * SIP/2.0 200 OK *:. Via: SIP/2.0/UDP 194.145.190.152:5065;branchb82l84b5laaelbba848f52b685l6Ob;received=1 94.145.190.152 *. Via: SIP/2.0/TCP * ** 193.93.7.53:5060;branch=z9hG4bK5oqlu7moegkji7vit8l0lrb;rport38285;re ceived=193.93.7.53 Record-Route: <sip:194.145.190.152:5065;r2on;lron> Record-Route: <sip:194.145.190.152:5065;transporttcp;r2on;lron> From: <sip:clientl@sip.test.aql.com>;tagggaekalkjdhc78eaO45q To: <sio:client2@sap.test.aql.com>;tag=as38aa8a73 Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R CSeq: 1350 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:client2@194.145.190.153> Content-Type: application/sdp Content-Length: 339 v=0 o=root 13930 13930 IN 1P4 194.145.190.153 s=session c=IN 1P4 194.145.190.153 t=0 0 m=audio 19228 RTP/AVP 8 0 3 18 97 98 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:18 G729/8000 fmtp:18 annexb=no a=rtpmap:97 iLBC/8000 artpmap: 98 telephone-event/8000 a=fmtp:98 0-16 a=silenceSupp:off ----SBC -> Client I "Nokia": SIP/2.0 200 01< Via: SIP/2.0/TCP 193.93.7.53:5060;branch=z9hG4bKsoqlu7moegkji7vit8lOlrb;rport=38285;re ceived=193. 93.7. 53 Record-Route: <sip:194.145.190.152:5065;r2on;lron> Record-Route: <s p:194.145.190.152:5065;transporttcp;r20n;lrOn> From: <sip:clientl@sip.test.aql.com>;tagggaekalkjdhc78ea045q To: <sip:client2@sip.test.aql.com>;tagas38aa8a73 Call-ID: 4PrGawsloTcTIM4bGFpoMOzplwdP9R CSeq: 1350 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:client2@194.145.190.153> Content-Type: application/sdp Content-Length: 339 v= 0 o=root 13930 13930 IN 1P4 194.145.190.153 s=sessiOfl c=IN 1P4 194.145.190.153 * ** t=0 0 *. m=audio 19228 RTP/AVP 8 0 3 18 97 98 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap: 97 iLBC/8000 * ,* a=rtpmap:98 telephone-event/8000 a-=fmtp:98 0-16 * asilenceSupp:off ----**.**S * S Client I "Nokia" -> SBC: AC!< sip:c1ent2@194.145.l90.153 SIP/2.0 Route: <sip: 194 145. 190. 152: 5065;transport=TCP;r2on;lr=on>, <sip: 194. 145. 190 152:5065; r2=on; lr=on> Via: SIP/2.0/TCP 193. 93.7 53: 5060;branch=z9hG4bKuj jlur6oOrqq47vit8idotj To: <sip:client2@sip.test.aql.com>;tagas38aa8a73 From: <sip:clientl@sip.test.aql.com>;tagggaekalk:dhc78eao4Sq Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R CSeq: 1350 ACK Supported: sec-agree Max-Forwards: 70 Proxy-Authorization: Digest realm="sip.test.aqi.com",nonce="01b44709",algOrithm=MD5,USername="Cli entl",uri="sip:sbc.test.aql.com:5065;transport=TCP',response="&49f4b4 a9a5f]ffdc8fOfe76f29e5O64" Content-Length: 0 -a.L. -. I -MSIerISIC ACK sip:client2@194.145.190.153 SIP/2.0 Record-route: <sip:194.145.190.152:5065;r2=on;lron> Record-route: <sip: 194.145.190.152: 5065;transport=tcp;r2=on;lr=on> Via: SIP/2.0/UDP 194.145. 190.152:5065;branch043d8e374a4bf4631d8b1be274db22 Via: SIP/2.0/TCP 193.93.7.53:5060;branch=z9hG4bKujjiur600rqq47vit8ldOtJ;rpOrt=38285;re cea.ved193. 93.7.53 To: <sip:client2@sip.test.aql.com>;tag=as38aa8a73 From: <sp:c1ient1@sip.test.aql.com>;tag=ggaekalkjdhc78ea045q Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R CSeq: 1350 ACK Supported: sec-agree Max-Forwards: 70 Proxy-Authorization: Digest realm="sip.test.aql.com",nonce="0lb44709",algorithrflMD5,userflame"cli ent1",uri="sip:sbc.test.aql.com:5065;traflsportTCP",responsea49f4b4 a9a5f7ffdc8fOfe76f29e5OE4" Content-Length: 0 Called Party hangs Up * ** Asterisk -> SBC: S...

*,,. BYE sip:clientl@192.168.0.6 SIP/2.0 Via: SIP/2.0/UDP 194.145.190.153:5060;branchz9hG4bK34af9bc2;rport * ** Route: * <sip:194.145.190.152:5065;r20n;lrofl>,<SiP:194.145.190.152:5065; tran * sport=tcp; r2=on; lr=on> From: <sip:client2@sip.test.aql.com>;tagas38aa8a73 To: <sip:clientl@sip.test.aql.com>;tagggaekalkjdhc78eaO45q * .. Contact: <sip:client2@194.145.190.153> Call-ID: 4 PrGawslolcl IM4bGFpoMOzplwdP9R CSeq: 102 BYE User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 SBC -> Client I "Nokia": BYE sip:clientl@192.168.0.6 SIP/2.0 Via: SIP/2.O/TCP 194.145.190.152:5065;branchbe917b4944ca88525776 Route: <sip: 194. 145. 190. 152: 5065;r2=on; lr=on>, <sip: 194. 145. 190. 152: 5065;tran sport=tcp; r2=on; lr=on> From: <sip:client2@sip.test.aql.com>;tag=as38aa8a73 To: <sip:clientl@sip.test.aql.com>;tag=ggaekalkjdhc78eaO45q Contact: <sip:client2@194.145.190.153> Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R CSeq: 102 BYE Max-Forwards: 70 Content-Length: 0 Client I "Nokia" -> SBC: SIP/2.0 200 OK Via: SIP/2.O/TCP 194.145.190.152:5065;branch=be917b4944ca88525776 To: <sip:c1ient1@sip.test.aql.com>;tag=ggaekaikjhc78ea045q From: <sip:client2@sip.test.aql.com>;tag=as3Baa8a73 Call-ID: 4PrGawsloIcIIM4bGFpoNOzplwdP9R CSeq: 102 BYE Content-Length: 0 SBC -> Asterisk: SIP/2.0 200 OK Record-route: <sip:194.145.190.152:5065;r2=on;lr=on> Record-route: <sip: 194.145.190. 152:5065;transport=tcp;r2=on;lr=on> Via: sIP/2.O/UDP 194.145.190.152:5065;branch=2cb438d93c4dee7b8558 Via: SIP/2.D/TCP 194.145.190.152: 5065;branchbe917b4944ca88525776;rport38285;received =193. 93. 7.53 To: <sip:clientl@sip.test.aql.com>; tag=ggaekalkjdhc78ea045q From: <sip:client2@sip.test.aql.com>;tag=as38aa8a73 Call-ID: 4PrGawsloIcIIM4bGFpoMOzplwdP9R CSeq: 102 BYE Content-Length: 0

CALL ENDS

Example
2. Client 2 Initiates Call to Client I "Nokia" I... * S S...

Asterisk -> SBC: INVITE sip:clientl@192.168.0.6;transport=TCP SIP/2.0 * . Via: SIP/2.O/UDP 194.145.190.153:5060;branch=z9hG4bK349c95c8;rport :. From: "James" <sip:client2@l94.145.190.153>;tag=as0d9dddel To: <sip:clentl@192.168.0.6;transport=TCP> Contact: <sip:client2@l94.145.190.153> Call-ID: 78f9e8183860465f58044c2e4cc0298c@194.145.190.153 * .. CSeq: 102 INVITE User-Agent: Asterisk PBX * Max-Forwards: 70 Date: Sat, 14 Oct 2006 17:39:17 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 342 v=0 o=root 13930 13930 IN 1P4 194.145.190.153 s=session c=IN 1P4 194.145.190.153 t=0 0 m=audio 19534 RTP/AVP 3 8 0 18 97 101 a=rtpmap: 3 GSM/8000 a=rtpinap: 8 PCMA/8000 a=rtpmap:0 PCMU/8000 artprnap:18 G729/8000 a=fmtp: 18 annexb=rio a=rtpmap:97 iLBC/8000 a=rtpmap: 101 telephone-event/8000 a=fmtp: 101 0-16 asi1enceSupp:off ----SBC -> Client I "Nokia": INVITE sip:clientl@192. 168.0.6;transport=TCP SIP/2.0 Via: SIP/2.O/TCP 194.145.190.152:5065;branch6aba77cd43faela4bl79 From: "James" <sip:client2@194.145.190.153>;tag=as0d9dddel To: <sip:clientl@192.168.0.6;transport=TCP> Contact: <sip:client2@194.145.190.153> Call-ID: 78f9e8183860465f58044c2e4cc0298c@194.145.190.153 CSeq: 102 INVITE Max-Forwards: 70 Date: Sat, 14 Oct 2006 17:39:17 GMT ALlow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Lengtn: 342 v=0 o=root 13930 13930 IN 1P4 194.145.190.153 ssessiofl c=IN IP4 194.145.190.153 t=0 0 m=audio 19534 RTP/AVP 3 8 0 18 97 101 a=rtpinap: 3 GSM/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 afmtp: 18 annexb=no * *e * . . a=rtpmap:97 iLBC/B000 * S. a=rtpmap: 101 telephone-event/8000 a=frntp:101 0-16 a=silenceSupp:off ----** S. * *S Cell proceeds in (he same nianner as the previous example. * S..

S * S. * . S * **

S 5.0.. * S