VOIP-Implementation of SIP-Assignment III

SCOPE
This Assignment requires the implementation on VOIP service between two organisations through their in-house Asterisk servers. Both the servers serving 2 VOIP phone extensions each through SIP, apart from trunking in between them. The dial plan should support overlapping numbers and hence an extension at each if the organisations should have overlapping names. Also, DHCP and DNS service should be built supporting the network architecture. As an extra effort , SIP servers have been built to support in-house presence information.
PC1

sip.voip.alpha.com

Virtual Switch

sip.voip.beta.com

C2950

PC2

Virtual Switch 1000 1001

1001

1002

ASSUMPTIONS
For simulating the network architecture following assumptions were made, 1) 2 Virtual Machines of which 1 runs Asterisk and DNS services and another runs Asterisk and DHCP services. In real time this may not be applicable, at least for the DHCP service. 2) A pair of X-Lite soft phones (on Windows7) and Ekiga (on Debian) soft phones are used to simulate real phones, each running on 4 separate virtual machines. 3) A single subnet 10.0.2.0/24 was chosen as suggested. 4) The two levels of IVR options to be built as a part of the dial plan are being tailored from the available sound files in the default collection as well as the asterisk-extra-sounds-en-ulawcurrent.tar package referred to in the SIP, Future of Telephony book. This could not support the names of the organisations and hence replaced with names viz. Engineering and Sales.

Ayyappan Ramanan 1144880

Page 1

VOIP-Implementation of SIP-Assignment III

5) The IVR plan is built so that when the user presses any button referring invalid extensions will be guided to proceed correctly. If the user knows a valid number, he can key in directly without being guided by IVR. This is thus built as to appeal sensibly. 6) When the extensions of one organisation try to call those of the other they should prepend a single digit code, as suggested. The SIP server strips the code and sends the number for the other SIP server to dial. 7) The IP addresses of the SIP Phones are not included into the zone files as they understood to be dynamically allocated by dhcp server. 8) The soft phones do not support VLANs. Hence instead if prioritizing the VLAN using Voice VLAN feature of Cisco 2950, packets are marked with COS value 5 and queued on Priority Q of the WRR Queues of C2950.

COURSE
1) The correct OS to run all the services on virtual machines needed critical choice. The Cent OS 5.5 was to run on Sun Virtual Box 3.1.8. 2) The soft phones were installed on VMs and Asterisk and Bind packages on server VMs and compiled. 3) The DHCP service was built to support disbursal of IP addresses in the entire subnet range except for the fixed VMs that require static bindings, especially the servers and to disseminate DNS server address and domain information. All these information is written in a file called dhcpd.conf before starting the service. 4) The BIND9 based DNS service built with two zones serving each of the organisations. Two zone files and a reverse mapping file all being referenced by named.conf in /etc directory. 5) Having started the DNS and DHCP services, they were tested by intermediate ping with their domain names. 6) Asterisk service on one of the servers is turned on. The extensions were defined in sip.conf with type as friend allowing calls both ways, secret as a preshared secret and the hosts ip address as dynamic and the contexts in a dial plan were defined in extensions.conf with just auto fall through configuration to test the setup. 7) The soft phones were configured with the credentials and the domain name of the server to dock on. 8) When one phone was turned on the other and the packets were sniffed, the registration process could be clearly comprehended and the phone came into service. 9) The dial plan was then upgraded to test the extension by defining a playback function that will play an audio file and then to hang up when call is made to a test extension. 10) The playback function is then upgraded to a two level IVR that would guide the user to dial a valid extension or quit. 11) With the success in the first phone the same procedure is repeated for the second soft phone. 12) The dial plan was then modified to enable the phones call each other, which was then verified by sniffers. With the limitations in VMs, the debug was not left to commands in the server.

Ayyappan Ramanan 1144880

Page 2

VOIP-Implementation of SIP-Assignment III

13) The second Asterisk server was brought into service with similar procedures servicing two other phones. One of the extensions shared its phone number with one on its counterpart in the neighbour organisation. 14) The sip.conf file was then modified with the command to register with each other with their own username and a shared secret. A context defining the account for each other to access and receive the respective incoming calls namely alpha and beta was defined on the respective servers. 15) Hitch! They could not register. Further investigations suggested the username define as user:secret@<server>/local context could not resolve the user as it was not and could not be defined in the DNS service. 16) The server domain name was then replaced by their respective IP addresses to fix this issue. 17) The extensions.conf was included with their respective contexts to server their counterparts. 18) Test calls were made from the extensions to their counterparts. Unfortuantely the overlapping phones could not reach each other. Hitch! 19) Logs showed authentication errors in the SIP channels, for the asterisk server could not allow an external caller conflicting with a local extension. 20) With a little of googled the issue was handled by disabling authentication by using insecure = invite,port on the extensions by trial and error method. This command in the external contexts caused an infinite loop and asterisk server had to be stopped forcibly. The possible reason might be the external contexts authenticating each other for a single request indefinitely. 21) The said command was tried with the local extensions and fixed the issue of calling between overlapped extensions. 22) The dial plan was finally cleaned up for proper AVR options and test calls were made end to end. 23) Call traces proved the operation adhered RFC 3261, We could now observe the SIP trapezoidal formation. 24) The vlan through which the set up was connected through a CISCO C2950 switch was put on the priority queue of WRR queues through the CISCO CLI. This could also be done with COS markings on the packets, but beyond the scope of this assignment. 25) As an extra effort the SIP presence was added to the local context in the extensions.conf with hint priority to give presence information on the extensions called, to the subscribers. The subscribers are the extensions which send SUBSCRIBE message to the SIP server advising on their capabilities, subscribing for presence service. 26) Various combinations were tried to implement cross border presence service but with failure. Only best thing could be done was to inform all the subscribers when a call is made by any of them. This feature was then removed to avoid misleading information. 27) The SIP presence was tested making test calls from the extensions.

CONCLUSION
This is an excellent assignment that offers room to study on the bones of SIP,VOIP, Virtual Machine management and MAC spoofing.

Ayyappan Ramanan 1144880

Page 3

VOIP-Implementation of SIP-Assignment III

CAPTURES
1) Time Sequence Diagram for calls between Phone1(1000) and Phone2(1001) both registered to SIP1 server Phone 1 INVITE>1 <TRYING1 INVITE>1 <TRYING1 <200OK <TRYING1 <180RINGING1 <180RINGING1 <200OK1 ACK1> <200OK1 INVITE>2 ACK>1 <INVITE2 200OK>2 <ACK2 <100TRYING2 <200OK2 ACK>2 <INVITE3 100TRYING>3 200OK>3 <ACK3 SIP1 Phone2

Ayyappan Ramanan 1144880

Page 4

VOIP-Implementation of SIP-Assignment III

CALL <BYE4 200OK>4 <INVITE5 100TRYING>5 200OK>5 <ACK5 <BYE5 200OK>6 a) Phone 1 intiates the call by sending Invite to SIP1, which in turn places an invite request with Phone 2, both of them defining themselves as connection points in SDP. Stream#1 b) Call is established by the 100,180 and 200 provisional responses

c) SIP1 starts first level of optimisation by sending invites in both the directions with the neighbour UAs IP address as connection point in SDP. Stream#2 d) Till the Phones directly communicate the SIP1 server tries optimising the call route. Stream#3

e) Phone to hangs up the call sending bye to SIP1 for it to take over. Stream #4 f) SIP1 takes over the session by sending invite to Phone1 and then hangs up the call. Stream #5.

2) A) Time Sequence Diagram for calls between Phone2(1001) registered to SIP1 and Phone4 (1002) registered to SIP2 server Non overlapping contexts Phone2 INVITE>1 <100 TRYING1 INVITE>1 <100 TRYING1 INVITE>1 SIP1 SIP2 Phone4

Ayyappan Ramanan 1144880

Page 5

VOIP-Implementation of SIP-Assignment III

<100 TRYING1 <180 RINGING1 <180 RINGING1 <180 RINGING1 <200 OK1 ACK>1 <200 OK1 INVITE>2 ACK>1 <200 OK1 INVITE>2 <INVITE2 <491 REQUEST PENDING5 ` 491 REQUEST PENDING>5 <ACK5 ACK>5 ACK>1 <INVITE2 <100 TRYING 2 200OK>2 <ACK2 <INVITE2 100TRY>2 200OK>2 ACK>2 <200OK2 ACK>2

Ayyappan Ramanan 1144880

Page 6

VOIP-Implementation of SIP-Assignment III

INVITE3> <INVITE3 100TRY>3 200OK>3 <ACK3 <100TRY3 <200OK3 ACK>3 <INVITE4 100TRY>4 200OK>4 <ACK4 INVITE>2 100TRY>2 200OK>2 <ACK2

CALL <BYE 6 200OK>6 <INVITE6 100TRY>6 200OK>6 <ACK6 <BYE6 200OK>6 <INVITE6

Ayyappan Ramanan 1144880

Page 7

VOIP-Implementation of SIP-Assignment III

100TRY>6 200K>6 <ACK6 <BYE6 200OK>6 a) When phone 2 initiates call it invites SIP1 for a session, which in turn invite SIP2 for a session and on. For clarity these chain of transactions has been appended by #1. It is to be noted that the UAs declare themselves as connection points. b) In sequel, we can see the provisional responses 100, 180 and 200 from phone4 to phone1 through the initiated route of sessions to build the call. c) Once the call is setup, RTP packets flows in the known unoptimal route all through the SIP servers. d) Once the SIP2 server receives 200 from Phone 4, it starts optimising the route to form the SIP Trapezoid by initiating chain of requests which is numbered # 2 for clarity. e) Note both SIP1 and SIP2 tries to optimize the path by throwing INVITE on either direction, which causes processor load and in turn requests in between them are denied by each other with 491. This exchange has been numbered #6. f) By the end of stream 2 both the SIP servers make the phone UAs agree to send their packet through their counterpart SIP servers, bypass their proxies to achieve one level of optimisation.

g) Before Phone 3 getting docked to SIP1 server the stream getting diverted as Phone2 SIP2 Phone4 h) Hence SIP1 resources are conserved. SIP2 initiates the second level of optimisation by initiation of stream #3 invites to both SIP1 and Phone 3. i) j) Since SIP1 is no longer the part of call it does not take this further with Phone 1 Phone3 however succeeds in fetching the IP address of Phone1 and directly routes its packets to Phone 1. Thus a triangular formation of Phone2 SIP2 Phone4 can be observed during the call.

k) It is to be noted that with the success of each level of optimisation the SIP servers again initiate Invites for the next level of optimisation. This is numbered # 4 (also trailing part of #2) l) Once Phone 4 hangs up, it sends a BYE to SIP2 which tries to modify the session, by including SIP1 into the loop and handing over the termination of the session to SIP1. This stream of requests has been numbered #6 for clarity. Page 8

Ayyappan Ramanan 1144880

VOIP-Implementation of SIP-Assignment III

m) SIP2 sends BYE to its session with SIP1, which in turn repeats the same with Phone 2 to terminate the call.

B) Time Sequence Diagram for calls between Phone2(1001) and Phone3(1001) both registered to SIP1 server overlapping contexts Phone1 INVITE>1 <100 TRYING1 INVITE>1 <100 TRYING1 INVITE>1 <100 TRYING1 <180 RINGING1 <180 RINGING1 <180 RINGING1 <200 OK1 ACK>1 <200 OK1 INVITE>2 ACK>1 <200 OK1 INVITE>2 <INVITE2 <491 REQUEST PENDING5 ` 491 REQUEST PENDING>5 <ACK5 ACK>5 ACK>1 SIP1 SIP2 Phone3

Ayyappan Ramanan 1144880

Page 9

VOIP-Implementation of SIP-Assignment III

<INVITE2 <100 TRYING 2 200OK>2 <ACK2 <INVITE2 100TRY>2 200OK>2 ACK>2 <200OK2 ACK>2 INVITE3> <INVITE3 100TRY>3 200OK>3 <ACK3 <100TRY3 <200OK3 ACK>3 <INVITE4 100TRY>4 200OK>4 <ACK4 INVITE>2 100TRY>2 200OK>2 <ACK2

Ayyappan Ramanan 1144880

Page 10

VOIP-Implementation of SIP-Assignment III

CALL <BYE 6 200OK>6 <INVITE6 100TRY>6 200OK>6 <ACK6 <BYE6 200OK>6 <INVITE6 100TRY>6 200K>6 <ACK6 <BYE6 200OK>6 n) When phone 1 initiates call it invites SIP1 for a session, which in turn invite SIP2 for a session and on. For clarity these chain of transactions has been appended by #1. It is to be noted that the UAs declare themselves as connection points. o) In sequel, we can see the provisional responses 100, 180 and 200 from phone3 to phone1 through the initiated route of sessions to build the call. p) Once the call is setup, RTP packets flows in the known unoptimal route all through the SIP servers. q) Once the SIP2 server receives 200 from Phone 3, it starts optimising the route to form the SIP Trapezoid by initiating chain of requests which is numbered # 2 for clarity. r) Note both SIP1 and SIP2 tries to optimize the path by throwing INVITE on either direction, which causes processor load and in turn requests in between them are denied by each other with 491. This exchange has been numbered #6. s) By the end of stream 2 both the SIP servers make the phone UAs agree to send their packet through their counterpart SIP servers, bypass their proxies to achieve one level of optimisation.

Ayyappan Ramanan 1144880

Page 11

VOIP-Implementation of SIP-Assignment III

t) Before Phone 3 getting docked to SIP1 server the stream getting diverted as Phone1 SIP2 Phone3 u) Hence SIP1 resources are conserved. SIP2 initiates the second level of optimisation by initiation of stream #3 invites to both SIP1 and Phone 3. v) Since SIP1 is no longer the part of call it does not take this further with Phone 1 w) Phone3 however succeeds in fetching the IP address of Phone1 and directly routes its packets to Phone 1. Thus a triangular formation of Phone1 SIP2 Phone3 can be observed during the call. x) It is to be noted that with the success of each level of optimisation the SIP servers again initiate Invites for the next level of optimisation. This is numbered # 4 (also trailing part of #2) y) Once Phone 3 Hangs up, it sends a BYE to SIP2 which tries to modify the session, by including SIP1 into the loop and handing over the termination of the session to SIP1. This stream of requests has been numbered #6 for clarity.

z) SIP2 sends BYE to its session with SIP1, which in turn repeats the same with Phone 1 to terminate the call. 3) BETWEEN PHONE AND ASTERISK SERVER A) 05:17:10.239186000 PHONE1 > SIP1

1>INVITE sip:91001@phones SIP/2.0 Invite a sip session with SIP1 2>Via:SIP/2.0/UDP 10.0.2.251:15458;branch=z9hG4bK-d8754z-cc3bd56218ceb5be-1---d8754z-;rport Path of the session recorded 3>Max-Forwards: 70 Defines maximum hops the request can take 4>Contact: sip:1001@10.0.2.251:15458 Defines the contact details for subsequent responses 5>To: sip:91001@phones Defines the logical recipient of the request the context in the proxy 6>From: <sip:1001@phones>;tag=c2713b23 Defines the logical initiator of the request the extension 7>Call-ID: NjZkM2FhZTc3YjYyYzc4MTVmMGEzMmMxYWI0MjZlZDY. Uniquely identifies the call 8>CSeq: 1 INVITE Sequence number of the transaction 9>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO All the methods supported by intiating UA 10>Content-Type: application/sdp Defines the contents of the application layer 11>Supported: replaces Ayyappan Ramanan 1144880 Page 12

VOIP-Implementation of SIP-Assignment III

Extensions supported defined as options 12>User-Agent: X-Lite 4 release 4.0 stamp 58832 Version details of the UA 13>Content-Length: 398 Length of the content in byte 14>v=0 SDP version 15>o=- 12930642644756722 1 IN IP4 10.0.2.251 Owner with unknown username, specified session ID, session version, network type IN, IPV4, owners IP address 16>s=CounterPath X-Lite 4.0 Session name 17>c=IN IP4 10.0.2.251 Connection network type, IPV4, connection address 18>t=0 0 Session start and stop time 19>a=ice-ufrag:02dcf7 Session attribute 20>a=ice-pwd:d2c761f97211f88ec6d79bfe6b739298 Session attribute 21>m=audio 55830 RTP/AVP 107 0 8 101 Media description: type, port, protocol, media format(codec info) 22>a=rtpmap:107 BV32/16000 Media attribute : fieldname, format, MIME type/sample rate 23>a=rtpmap:101 telephone-event/8000 Same as 22 24>a=fmtp:101 0-15 Media attribute : fieldname : value 25>a=sendrecv Media attribute: value 26>a=candidate:1 1 UDP 659136 10.0.2.251 55830 typ host Same as 24 27>a=candidate:1 2 UDP 659134 10.0.2.251 55831 typ host Same as 24 B) 46 10.391447000 SIP1 > Phone 1

28>SIP/2.0 100 Trying SIP1 acknowleges the INVITE request sent by Phone1 (packet A) 29>Via: SIP/2.0/UDP 10.0.2.251:15458;branch=z9hG4bK-d8754z-cc3bd56218ceb5be-1---d8754z;received=10.0.2.251;rport=15458 Matches VIA in the request, line 2 30>From: <sip:1001@phones>;tag=c2713b23 Matches From in the request, line 6 Ayyappan Ramanan 1144880 Page 13

VOIP-Implementation of SIP-Assignment III

31>To: sip:91001@phones Matches To in the request, line 5 32>Call-ID: NjZkM2FhZTc3YjYyYzc4MTVmMGEzMmMxYWI0MjZlZDY. Matches the call Id in request, line 7 33>CSeq: 1 INVITE Matches sequence line 8 34>Server: Asterisk PBX 1.6.2.11 Server version 35>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO All the methods supported by server 36>Supported: replaces, timer SIP Extensions supported by the server 37>Contact: sip:91001@10.0.2.17 Offers contact details for future messages 38>Content-Length: 0 Specifies the message body is empty <packets between SIP1 and SIP2 servers omitted> C) 121 30.903538000 SIP1 > Phone1 SIP Status: 180 Ringing This informational SIP message is proposed by the SIP1 server on receipt of a similar message from SIP2 regarding the call suggesting the intended extension is being alerted. 39>SIP/2.0 180 Ringing This informational SIP message is proposed by the SIP1 server on receipt of a similar message from SIP2 regarding the call suggesting the intended extension is being alerted. 40>Via: SIP/2.0/UDP 10.0.2.251:15458;branch=z9hG4bK-d8754z-cc3bd56218ceb5be-1---d8754z;received=10.0.2.251;rport=15458 Path record matches line 2 41>From: <sip:1001@phones>;tag=c2713b23 Matches line 6 42>To: <sip:91001@phones>;tag=as7b8c863b Matches line 5 43>Call-ID: NjZkM2FhZTc3YjYyYzc4MTVmMGEzMmMxYWI0MjZlZDY. Matches line 7 44>CSeq: 1 INVITE Matches line 8 45>Server: Asterisk PBX 1.6.2.11 46>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO 47>Supported: replaces, timer 48>Contact: sip:91001@10.0.2.17 Same as 37 49>Content-Length: 0 Empty packet ,<packets omitted> Ayyappan Ramanan 1144880 Page 14

VOIP-Implementation of SIP-Assignment III

D) 150 35.429078000 10.0.2.17 10.0.2.251 SIP/SDP Status: 200 OK, with session description 50>SIP/2.0 200 OK Informs the caller that the session request has succeeded. Other fields same as packet C 51>Via: SIP/2.0/UDP 10.0.2.251:15458;branch=z9hG4bK-d8754z-cc3bd56218ceb5be-1---d8754z;received=10.0.2.251;rport=15458 52>From: <sip:1001@phones>;tag=c2713b23 53>To: <sip:91001@phones>;tag=as7b8c863b 54>Call-ID: NjZkM2FhZTc3YjYyYzc4MTVmMGEzMmMxYWI0MjZlZDY. 55>CSeq: 1 INVITE 56>Server: Asterisk PBX 1.6.2.11 57>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO 58>Supported: replaces, timer 59>Contact: <sip:91001@10.0.2.17> 60>Content-Type: application/sdp 61>Content-Length: 255 SESSION DESCRIBED by SIP2 on behalf of Phone1 of SIP2 similar to SDP proposed by Phone 1 62>v=0 63>o=root 1303614104 1303614104 IN IP4 10.0.2.17 Ip address specified here is session owner 64>s=Asterisk PBX 1.6.2.11 65>c=IN IP4 10.0.2.17 Connection ip address 66>t=0 0 67>m=audio 18504 RTP/AVP 0 8 101 68>a=rtpmap:0 PCMU/8000 69>a=rtpmap:8 PCMA/8000 70>a=rtpmap:101 telephone-event/8000 71>a=fmtp:101 0-16 72>a=ptime:20 73>a=sendrecv E) 163 35.537784000 Phone1>SIP1 SIP Request: ACK sip:91001@10.0.2.17

74>ACK sip:91001@10.0.2.17 SIP/2.0 Phone1 acknowledges packet D for reliability. Remaining fields same as that of packet A 75>Via: SIP/2.0/UDP 10.0.2.251:15458;branch=z9hG4bK-d8754z-da39ae5e2549b0e2-1---d8754z;rport Max-Forwards: 70 Contact: <sip:1001@10.0.2.251:15458> To: <sip:91001@phones>;tag=as7b8c863b From: <sip:1001@phones>;tag=c2713b23 Call-ID: NjZkM2FhZTc3YjYyYzc4MTVmMGEzMmMxYWI0MjZlZDY. CSeq: 1 ACK Ayyappan Ramanan 1144880 Page 15

VOIP-Implementation of SIP-Assignment III

User-Agent: X-Lite 4 release 4.0 stamp 58832 Content-Length: 0 F) 164 35.542622 SIP1 > Phone 1 SIP/SDP Request: INVITE sip:1001@10.0.2.251:15458, with session description This is to establish the a return session G) 173 35.629473 Phone1> SIP1 SIP/SDP Status: 200 OK, with session description Phone confirms the return session has succeeded H) 174 35.630607 SIP1>Phone1 SIP Request: ACK sip:1001@10.0.2.251:15458 SIP server acknowledges the session success I ) Packets F, G, H repeated through out the SDP negotiation J) The Call (RTP) between the phones is then routed through SIP 1 and finally both the phones speak directly proving the statelessness. K) Occasionally the SIP servers intervene the session, Proably for session modification procedures. L) When the call is terminated by the called Phone 533 39.631801 SIP1> Phone 1 SIP Request: BYE sip:1001@10.0.2.251:15458 76> BYE sip:1001@10.0.2.251:15458 SIP/2.0 SIP1 terminates the session with Phone 1, with the contents same as the other packets of the session between them Via: SIP/2.0/UDP 10.0.2.17:5060;branch=z9hG4bK05494aed;rport Max-Forwards: 70 From: <sip:91001@phones>;tag=as7b8c863b To: <sip:1001@phones>;tag=c2713b23 Call-ID: NjZkM2FhZTc3YjYyYzc4MTVmMGEzMmMxYWI0MjZlZDY. CSeq: 104 BYE User-Agent: Asterisk PBX 1.6.2.11 77>X-Asterisk-HangupCause: Normal Clearing Cause of the session termination 78>X-Asterisk-HangupCauseCode: 16 79>Content-Length: 0 4) Capture of exchange of presence information between SIP1 and Phone 1. a) 284 44.356822 sip:phones b) 285 44.357220 (0 bindings) c) 286 44.363940 sip:phones d) 287 44.367779 bindings) e) 289 44.410106 sip:1001@phones f) 292 44.413208 mailbox) Ayyappan Ramanan 1144880 10.0.2.254 10.0.2.17 10.0.2.254 10.0.2.17 10.0.2.254 10.0.2.17 10.0.2.17 10.0.2.254 10.0.2.17 10.0.2.254 10.0.2.17 10.0.2.254 SIP SIP SIP SIP SIP SIP Request: REGISTER

Status: 401 Unauthorized Request: Status: 200 OK Request: REGISTER (1

SUBSCRIBE

Status: 404 Not found (no

Page 16

VOIP-Implementation of SIP-Assignment III

g) 293 44.413212 10.0.2.17 10.0.2.254 SIP Status: 200 OK

The SIP1 server notifies Phone1 on the registration of Phone 2. h) 294 44.413213 10.0.2.17 10.0.2.254 SIP/XML sip:1001@10.0.2.254:12782 NOTIFY sip:1001@10.0.2.254:12782 SIP/2.0 Via: SIP/2.0/UDP 10.0.2.17:5060;branch=z9hG4bK717a7413;rport Max-Forwards: 70 From: <sip:1002@phones>;tag=as281b23b7 To: <sip:1001@phones>;tag=d232f0a4 Contact: <sip:1002@10.0.2.17> Call-ID: OWUyMzQ1NjY5YzYwY2QzYmQ0ZWEwMzkxYzdmZjhkYWU. CSeq: 102 NOTIFY User-Agent: Asterisk PBX 1.6.2.11 Event: presence Content-Type: application/pidf+xml Subscription-State: active Content-Length: 467 <?xml version="1.0" encoding="ISO-8859-1"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:pp="urn:ietf:params:xml:ns:pidf:person" xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status" xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person" entity="sip:1001@phones"> <pp:person><status> </status></pp:person> <note>Ready</note> <tuple id="1002"> <contact priority="1">sip:1002@phones</contact> <status><basic>open</basic></status> </tuple> </presence>

Request:

NOTIFY

Ayyappan Ramanan 1144880

Page 17