From sip-bounces@ietf.org  Wed Dec  1 02:01:16 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11564
	for <sip-web-archive@ietf.org>; Wed, 1 Dec 2004 02:01:16 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZOZY-0000Dx-4q
	for sip-web-archive@ietf.org; Wed, 01 Dec 2004 02:06:44 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZONw-0001sG-Ac; Wed, 01 Dec 2004 01:54:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZOIu-00080L-Qh; Wed, 01 Dec 2004 01:49:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10004;
	Wed, 1 Dec 2004 01:49:31 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZOOB-0008NW-7y; Wed, 01 Dec 2004 01:54:59 -0500
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP;
	Wed, 1 Dec 2004 07:48:54 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <X53D03V5>; Wed, 1 Dec 2004 07:27:57 +0100
Message-Id: <E7666D92C64C2845AEF12636FF94F952F97513@S4DE8PSAAGQ.blf.telekom.de>
From: "Jesske, R" <R.Jesske@t-com.net>
To: taylor@nortelnetworks.com
Date: Wed, 1 Dec 2004 07:27:54 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: quoted-printable
Cc: An.Nguyen@ncs.gov, sip@ietf.org, iptel@ietf.org, oran@cisco.com,
        Mpierce1@aol.com
Subject: [Sip] AW:  Calling Party's Category
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: quoted-printable

Dear Tom, all,
I see there are several questions with regard to the CPC. Our approach =
is to use it for billing, charge info and routing purposes.

Payphone:
1. Payphone Calls are routed in an other manner than normal calls
2. Payphone Calls are billed differently compared with normal calls
3. The charge information shown to the user of the payphone is an other =
than for normal once
4. Based on the CPC a blocking of numbers (e.G premium rate or special =
destinations) can be performed
5. Special accounting mechanisms for free phone numbers are possible

A question was how to perform security and trust. Using the CPC within =
the P-Asserted-ID makes this information trusted. The UA can advice =
with the P-Preferred-ID that the SIP Proxy should use the proposed URI =
as P-Asserted-ID. But Proxy verifies this information. If the =
Information in the Hint is not correct the dialog will be candled or =
the stored ID will be provided by the network.

Best Regards

Roland

  =20


-----Urspr=FCngliche Nachricht-----
Von: Tom Taylor [mailto:taylor@nortelnetworks.com]
Gesendet: Dienstag, 30. November 2004 19:51
An: Nguyen, An
Cc: iptel@ietf.org; sipping@ietf.org; Jesske, Roland
Betreff: Re: [Iptel] Calling Party's Category


Jonathan, I hope I am stating this correctly.

The Chair's proposal at the meeting was that this draft be dropped, =
because with=20
SIP-T defined, there is no need to define other means in SIP to carry =
signalling=20
destined specifically to the PSTN.  However, if use cases can be =
provided which=20
demonstrate a requirement to be met in the pure SIP environment, work =
can be done=20
(probably in SIPPING) to meet those requirements.

Nguyen, An wrote:
> Mr. Taylor;
>=20
> I am just curious ... What is the status of the Internet Draft?
>=20
> An
>=20
>=20
[snip]

--=20
Tom Taylor
Carrier VoIP Standards Development
Nortel Networks
Phone +1 613 763 1496  (ESN 393-1496)
E-mail: taylor@nortelnetworks.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From mailman-bounces@ietf.org  Wed Dec  1 09:06:10 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00467
	for <sip-web-archive@ietf.org>; Wed, 1 Dec 2004 09:06:10 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZVCp-0000kS-Ur
	for sip-web-archive@ietf.org; Wed, 01 Dec 2004 09:11:44 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZSfo-0002dW-1L
	for sip-web-archive@ietf.org; Wed, 01 Dec 2004 06:29:28 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: ietf.org mailing list memberships reminder
From: mailman-owner@ietf.org
To: sip-web-archive@ietf.org
X-No-Archive: yes
Message-ID: <mailman.23040.1101898192.3553.mailman@lists.ietf.org>
Date: Wed, 01 Dec 2004 05:49:52 -0500
Precedence: bulk
X-BeenThere: mailman@lists.ietf.org
X-Mailman-Version: 2.1.5
List-Id: Mailman site list <mailman.lists.ietf.org>
X-List-Administrivia: yes
Sender: mailman-bounces@ietf.org
Errors-To: mailman-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, mailman-request@ietf.org) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

**********************************************************************

NOTE WELL:

Any submission to the IETF intended by the Contributor for publication
as all or part of an IETF Internet-Draft or RFC and any statement made
within the context of an IETF activity is considered an "IETF
Contribution". Such statements include oral statements in IETF
sessions, as well as written and electronic communications made at any
time or place, which are addressed to:

o the IETF plenary session, o any IETF working group or portion
thereof, o the IESG, or any member thereof on behalf of the IESG, o
the IAB or any member thereof on behalf of the IAB, o any IETF mailing
list, including the IETF list itself, any working group
  or design team list, or any other list functioning under IETF
auspices,
o the RFC Editor or the Internet-Drafts function

All IETF Contributions are subject to the rules of RFC 3667 and RFC
3668.

Statements made outside of an IETF session, mailing list or other
function, that are clearly not intended to be input to an IETF
activity, group or function, are not IETF Contributions in the context
of this notice.

Please consult RFC 3667 for details.

*******************************************************************************


If you have questions, problems, comments, etc, send them to
mailman-owner@ietf.org.  Thanks!

Passwords for sip-web-archive@ietf.org:

List                                     Password // URL
----                                     --------  
sip@ietf.org                             toufat    
https://www1.ietf.org/mailman/options/sip/sip-web-archive%40ietf.org


From sip-bounces@ietf.org  Wed Dec  1 12:30:57 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00594
	for <sip-web-archive@ietf.org>; Wed, 1 Dec 2004 12:30:57 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZYP0-0005ll-MX
	for sip-web-archive@ietf.org; Wed, 01 Dec 2004 12:36:32 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZXSa-0005bD-19; Wed, 01 Dec 2004 11:36:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZVkZ-0001ew-Jy; Wed, 01 Dec 2004 09:46:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04734;
	Wed, 1 Dec 2004 09:46:34 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZVpt-0001WC-5d; Wed, 01 Dec 2004 09:52:06 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 01 Dec 2004 07:53:19 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB1EjxPr019514;
	Wed, 1 Dec 2004 06:46:00 -0800 (PST)
Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com
	[10.32.245.156])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id iB1EjRbI009035;
	Wed, 1 Dec 2004 06:45:27 -0800
In-Reply-To: <E7666D92C64C2845AEF12636FF94F952F97513@S4DE8PSAAGQ.blf.telekom.de>
References: <E7666D92C64C2845AEF12636FF94F952F97513@S4DE8PSAAGQ.blf.telekom.de>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <B4E1F746-43A7-11D9-8CD3-000A95C73842@cisco.com>
Content-Transfer-Encoding: quoted-printable
From: David R Oran <oran@cisco.com>
Subject: Re: [Sip] AW:  Calling Party's Category
Date: Wed, 1 Dec 2004 09:45:55 -0500
To: R Jesske <R.Jesske@t-com.net>
X-Mailer: Apple Mail (2.619)
IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1101912328.473237"; x:"432200"; a:"rsa-sha1"; b:"nofws:4226";
	e:"Iw==";
	n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw"
	"eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU"
	"tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"X9YGOMPn5Yu/li9CqnRQhXpd86H2OFRRa60/YOY7mfXDR1lKvXrYKdg1lIFqi"
	"CifaZA/I3wT2QqJoOOrQhKrxK2rDoJdbMlimkyhV1TsXAJ7I8K+5JTgzE71pz"
	"W3/9Pg9FelHD//iveGUgTWYMCIJPtUJK/6BKPn3ptutE1stNc=";
	c:"From: David R Oran <oran@cisco.com>";
	c:"Subject: Re: [Sip] AW:  Calling Party's Category";
	c:"Date: Wed, 1 Dec 2004 09:45:55 -0500"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Content-Transfer-Encoding: quoted-printable
Cc: list iptel <iptel@ietf.org>, "'sip@ietf.org'" <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Content-Transfer-Encoding: quoted-printable

Just curious - what does it take to get a CPC code point allocated? If=20=

the IETF is to put this into SIP somehow, this issue will undoubtedly=20
come up (as it did in spades for ENUM).

So, let's assume I want to have a CPC called "Bordello", with the=20
following characteristics
- Calls to normal destinations are allowed and billed to the associated=20=

subscriber account
- Calls to the police are blocked
- Incoming calls are diverted to a sexy autoattendant.
- Calls to residences of known customers (provisioned by bordello=20
owner) are anonymized, or alternatively obfuscated with a location=20
header showing the origin is elsewhere.

The following questions obtain:
a) who allocates the "Bordello" codepoint?
b) what is the scope of the allocation?
c) where are the semantics documented (e.g. RFC, part of registration,=20=

etc.)
d) how does it interact with other call handling related functions?

this is beginning to look suspiciously like the "Namespace" discussion=20=

with respect to resource-priority, isn't it?

After thinking about this some more, I feel even more strongly along=20
the lines Jon Peterson suggested - don't put this into SIP; instead=20
deal with it as a role assertion through a SAML document provided as=20
part of the (enhanced) identity work when we get around to it.

This comprises yet another use case for SAML (besides delegation) which=20=

may argue for our being more aggressive about moving this forward right=20=

on the heels of the identity work. Anyone want to tackle this with an=20
i.d.?

Dave.

On Dec 1, 2004, at 1:27 AM, Jesske, R wrote:

> Dear Tom, all,
> I see there are several questions with regard to the CPC. Our approach=20=

> is to use it for billing, charge info and routing purposes.
>
> Payphone:
> 1. Payphone Calls are routed in an other manner than normal calls
> 2. Payphone Calls are billed differently compared with normal calls
> 3. The charge information shown to the user of the payphone is an=20
> other than for normal once
> 4. Based on the CPC a blocking of numbers (e.G premium rate or special=20=

> destinations) can be performed
> 5. Special accounting mechanisms for free phone numbers are possible
>
> A question was how to perform security and trust. Using the CPC within=20=

> the P-Asserted-ID makes this information trusted. The UA can advice=20
> with the P-Preferred-ID that the SIP Proxy should use the proposed URI=20=

> as P-Asserted-ID. But Proxy verifies this information. If the=20
> Information in the Hint is not correct the dialog will be candled or=20=

> the stored ID will be provided by the network.
>
> Best Regards
>
> Roland
>
>
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: Tom Taylor [mailto:taylor@nortelnetworks.com]
> Gesendet: Dienstag, 30. November 2004 19:51
> An: Nguyen, An
> Cc: iptel@ietf.org; sipping@ietf.org; Jesske, Roland
> Betreff: Re: [Iptel] Calling Party's Category
>
>
> Jonathan, I hope I am stating this correctly.
>
> The Chair's proposal at the meeting was that this draft be dropped,=20
> because with
> SIP-T defined, there is no need to define other means in SIP to carry=20=

> signalling
> destined specifically to the PSTN.  However, if use cases can be=20
> provided which
> demonstrate a requirement to be met in the pure SIP environment, work=20=

> can be done
> (probably in SIPPING) to meet those requirements.
>
> Nguyen, An wrote:
>> Mr. Taylor;
>>
>> I am just curious ... What is the status of the Internet Draft?
>>
>> An
>>
>>
> [snip]
>
> --=20
> Tom Taylor
> Carrier VoIP Standards Development
> Nortel Networks
> Phone +1 613 763 1496  (ESN 393-1496)
> E-mail: taylor@nortelnetworks.com
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran@cisco.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec  1 13:24:18 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06156
	for <sip-web-archive@ietf.org>; Wed, 1 Dec 2004 13:24:18 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZZEe-0007S4-JD
	for sip-web-archive@ietf.org; Wed, 01 Dec 2004 13:29:53 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZYD3-0000vS-Jp; Wed, 01 Dec 2004 12:24:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZXGC-0007WH-8L; Wed, 01 Dec 2004 11:23:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20306;
	Wed, 1 Dec 2004 11:23:18 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZXLT-0003mT-Px; Wed, 01 Dec 2004 11:28:52 -0500
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-1.cisco.com with ESMTP; 01 Dec 2004 11:31:12 -0500
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com
	[64.102.16.27])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB1GMfgl012748; 
	Wed, 1 Dec 2004 11:22:42 -0500 (EST)
Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-112.cisco.com
	[64.100.229.112]) by fruitpie.cisco.com (MOS 3.4.6-GR)
	with ESMTP id BDS08047; Wed, 1 Dec 2004 08:22:40 -0800 (PST)
Message-Id: <4.3.2.7.2.20041201104828.00c20590@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 01 Dec 2004 11:22:39 -0500
To: Adam Roach <adam@nostrum.com>, David R Oran <oran@cisco.com>
From: Mike Hammer <mhammer@cisco.com>
Subject: Re: [Sip] RE: [Iptel] Calling Party's Category
In-Reply-To: <41ACC997.40206@nostrum.com>
References: <23EA088E-42EC-11D9-8CD3-000A95C73842@cisco.com>
	<49E7012A614B024B80A7D175CB9A64ECB0491A@ftrdmel1.rd.francetelecom.fr>
	<23EA088E-42EC-11D9-8CD3-000A95C73842@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: "Jesske, R" <R.Jesske@t-com.net>, iptel@ietf.org,
        Tom Taylor <taylor@nortelnetworks.com>, sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac

At 01:27 PM 11/30/2004 -0600, Adam Roach wrote:
>David R Oran wrote:
>
>>
>>On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote:
>>
>>>As an fixed line operator we also are interested in this feature and 
>>>would be happy that the IETF finally moves forward with this draft. This 
>>>type of parameter is widely signalled in ISDN/PSTN networks. In SIP (for 
>>>example) it is required in context of both:
>>>
>>>- pure SIP networks (e.g. in case of a SIP payphone), and
>>>- interworking with legacy networks
>>>
>>>I think the uses case for this parameter will depend on the operator 
>>>service portfolio. For example, in France, the calling party's category 
>>>parameter is used for the Call Return service.
>>Could you explain a bit about how this is used? I, for one would find it 
>>helpful and possibly a motivating use case.
>
>
>I'm equally confused. I'm familiar with the calling party category in 
>ISUP, which works only because of the walled-garden nature of the SS7 
>network. Without that, there are really two major factors around this 
>which need to be characterized:
>
>   1. Who is authorized to assert a particular calling party category?
>      This is much trickier than the identity problem; with identity, we
>      can trust that a domain is the authority for the use of user names
>      in that domain. For calling party category, there is no such
>      relationship. For example, it would probably not be valid for a
>      domain of "adamroach.com" to assert a calling party category of
>      "priority," "operator," or "police."
>   2. Under which circumstances is the calling party category required
>      to be present? Is there some architectural mechanism that can be
>      used to enforce this? (We don't need to define it, but there
>      should at least be some idea about whether it's possible). If not,
>      then there is no purpose in coming up with a protocol mechanism
>      for conveying such information.
>
>/a
>
>_______________________________________________
>Iptel mailing list
>Iptel@ietf.org
>https://www1.ietf.org/mailman/listinfo/iptel

The underlying assumption of the base peer-peer architectural model is that 
the peers have a mechanism to do end-end security and can establish direct 
trust between the ends.  But, this does not hold much water when one end is 
intentionally betraying trust.  That begs for middleman enforcement.

What happens when:
the calling endpoint can not be trusted,
a middle point proxy can be trusted to know the calling endpoint,
the called endpoint could trust the middle device?

The issue seems to be that we have an end to middle security requirements 
(draft-ietf-sipping-e2m-sec-reqs-04), but not a middle to end security 
requirements, whereby the called end does not trust the caller, but could 
establish trust of the middle with appropriate mechanisms.

Granted this leads back to a walled garden sort of approach to things, but 
walls may serve a purpose.  But, instead of thinking of this as an 
impedance to traffic, better to consider this as a truthful attribution of 
traffic as it is allowed to traverse domain boundaries.  Trust comes from 
authenticity of information and in some cases middlemen are needed to 
enforce that.  Otherwise, expect spam, spit, wormy, virus-sick networks.

Mike


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec  1 14:31:53 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14808
	for <sip-web-archive@ietf.org>; Wed, 1 Dec 2004 14:31:53 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZaI5-0001XF-Pi
	for sip-web-archive@ietf.org; Wed, 01 Dec 2004 14:37:29 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZZTe-0006OW-Aj; Wed, 01 Dec 2004 13:45:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZYk4-0002dF-At; Wed, 01 Dec 2004 12:58:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04438;
	Wed, 1 Dec 2004 12:58:13 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZYpQ-0006vS-1L; Wed, 01 Dec 2004 13:03:48 -0500
Received: from apache by megatron.ietf.org with local (Exim 4.32)
	id 1CZXyx-0002qJ-DO; Wed, 01 Dec 2004 12:09:35 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1CZXyx-0002qJ-DO@megatron.ietf.org>
Date: Wed, 01 Dec 2004 12:09:35 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: sip mailing list <sip@ietf.org>, sip chair <rohan@ekabal.com>,
        Internet Architecture Board <iab@iab.org>,
        sip chair <dean.willis@softarmor.com>,
        RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Sip] Protocol Action: 'Usage of the Session Description Protocol 
 (SDP) Alternative Network Address Types (ANAT) Semantics in the 
 Session Initiation Protocol (SIP)' to Proposed Standard 
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15

The IESG has approved the following document:

- 'Usage of the Session Description Protocol (SDP) Alternative Network Address 
   Types (ANAT) Semantics in the Session Initiation Protocol (SIP) '
   <draft-ietf-sip-anat-usage-00.txt> as a Proposed Standard

This document is the product of the Session Initiation Protocol Working Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

Technical Summary

   This document describes how to use the Alternative Network
   Address Types (ANAT) semantics of the SDP
   grouping framework in SIP. In particular, we define the sdp-anat SIP
   option-tag. This SIP option-tag ensures that SDP session descriptions
   using ANAT are only handled by SIP entities with ANAT support. 

   The document describes the issues if SIP entities interpret ANAT media 
   grouping without the expectation that an option-tag will identify them.

   ANAT media groupings allow a SIP entity to signal its peer that it
   has both IPv4 and IPv6 address support (within SDP's ability to
   express both families).  There is no presumption of how these
   addresses should be chosen by the two peers, but the ANAT grouping
   in SDP supports the application's use of ICE (Interactive Connectivity
   Establishment) RFC 3424-aware NAT traversal methodology.
 
Working Group Summary

  This draft was developed because draft-ietf-mmusic-anat required a
  SIP option-tag for use with SIP.  The SIP Working Group supported 
  working group adoption and advancement of the draft. 
 
Protocol Quality
 
 The specification was reviewed for the IESG by Allison Mankin.
 Some discussion was needed to require strong error handling.  

RFC Editor Note:

Expand the first appearance of ANAT in the Abstract and the
Introduction  -  Alternative Network Address Types

Security Considerations

OLD:
   The natural choice to integrity
   protect header fields in SIP is S/MIME.

NEW:
   The natural choice to integrity
   protect header fields in SIP is S/MIME. [RFC3853]

 And please add a normative reference to RFC 3853.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec  1 16:40:58 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28398
	for <sip-web-archive@ietf.org>; Wed, 1 Dec 2004 16:40:58 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZcIz-0005RP-Aj
	for sip-web-archive@ietf.org; Wed, 01 Dec 2004 16:46:34 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZbgK-0004GB-TL; Wed, 01 Dec 2004 16:06:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZazW-0003jW-0v; Wed, 01 Dec 2004 15:22:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20509;
	Wed, 1 Dec 2004 15:22:18 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZb4s-0002r0-N0; Wed, 01 Dec 2004 15:27:56 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-1.cisco.com with ESMTP; 01 Dec 2004 12:28:11 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB1KLdAO025157;
	Wed, 1 Dec 2004 12:21:40 -0800 (PST)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com
	[171.68.225.134]) by wells.cisco.com (8.8.6
	(PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA11511;
	Wed, 1 Dec 2004 12:21:45 -0800 (PST)
Message-Id: <4.3.2.7.2.20041201141520.0309f258@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 01 Dec 2004 14:21:56 -0600
To: David R Oran <oran@cisco.com>, R Jesske <R.Jesske@t-com.net>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [Sip] AW:  Calling Party's Category
In-Reply-To: <B4E1F746-43A7-11D9-8CD3-000A95C73842@cisco.com>
References: <E7666D92C64C2845AEF12636FF94F952F97513@S4DE8PSAAGQ.blf.telekom.de>
	<E7666D92C64C2845AEF12636FF94F952F97513@S4DE8PSAAGQ.blf.telekom.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 1.1 (+)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: list iptel <iptel@ietf.org>, "'sip@ietf.org'" <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f

At 09:45 AM 12/1/2004 -0500, David R Oran wrote:
>....this is beginning to look suspiciously like the "Namespace" discussion 
>with respect to resource-priority, isn't it?
>
>After thinking about this some more, I feel even more strongly along the 
>lines Jon Peterson suggested - don't put this into SIP; instead deal with 
>it as a role assertion through a SAML document provided as part of the 
>(enhanced) identity work when we get around to it.
>
>This comprises yet another use case for SAML (besides delegation) which 
>may argue for our being more aggressive about moving this forward right on 
>the heels of the identity work. Anyone want to tackle this with an i.d.?

How would this new ID idea be different than:
http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-01.txt ?

The above is the answer doc to the requirements ID we authors have been 
kinda dragging out feet about revving at:
http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-trait-authz-00.txt
but we think is essentially done once revved.


>Dave.


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec  1 16:53:49 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00050
	for <sip-web-archive@ietf.org>; Wed, 1 Dec 2004 16:53:49 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZcVQ-0005nt-Vn
	for sip-web-archive@ietf.org; Wed, 01 Dec 2004 16:59:26 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZbgk-0004az-KO; Wed, 01 Dec 2004 16:07:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZbML-0006lO-8i; Wed, 01 Dec 2004 15:45:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22234;
	Wed, 1 Dec 2004 15:45:55 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZbRi-0003a7-EB; Wed, 01 Dec 2004 15:51:31 -0500
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-4.cisco.com with ESMTP; 01 Dec 2004 12:45:05 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iB1KjIRR020606;
	Wed, 1 Dec 2004 12:45:19 -0800 (PST)
Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com
	[10.32.245.156])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id iB1KihPJ012348;
	Wed, 1 Dec 2004 12:44:45 -0800
In-Reply-To: <4.3.2.7.2.20041201141520.0309f258@localhost>
References: <E7666D92C64C2845AEF12636FF94F952F97513@S4DE8PSAAGQ.blf.telekom.de>
	<E7666D92C64C2845AEF12636FF94F952F97513@S4DE8PSAAGQ.blf.telekom.de>
	<4.3.2.7.2.20041201141520.0309f258@localhost>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <E4EAF96A-43D9-11D9-8CD3-000A95C73842@cisco.com>
Content-Transfer-Encoding: 7bit
From: David R Oran <oran@cisco.com>
Subject: Re: [Sip] AW:  Calling Party's Category
Date: Wed, 1 Dec 2004 15:45:11 -0500
To: "James M. Polk" <jmpolk@cisco.com>
X-Mailer: Apple Mail (2.619)
IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1101933889.334612"; x:"432200"; a:"rsa-sha1"; b:"nofws:1477";
	e:"Iw==";
	n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw"
	"eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU"
	"tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"VLMbMoUhLy5jmQYzzfJPKmBwXZE5MvXOuCnZPyFAOXLfpCHUmpb48oAbC9LLK"
	"SaWlsxMjXTlKopHOnYAy7MeHPjzHCn3xgXtPLHXczM0A+e9UQN4+tzHKNWEx4"
	"rDAxgERlYHFTF+aYjfOUJ1YLzWiSR4scKiO0OepZ3lnh22GuI=";
	c:"From: David R Oran <oran@cisco.com>";
	c:"Subject: Re: [Sip] AW:  Calling Party's Category";
	c:"Date: Wed, 1 Dec 2004 15:45:11 -0500"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Cc: "'sip@ietf.org'" <sip@ietf.org>, list iptel <iptel@ietf.org>,
        R Jesske <R.Jesske@t-com.net>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit


On Dec 1, 2004, at 3:21 PM, James M. Polk wrote:

> At 09:45 AM 12/1/2004 -0500, David R Oran wrote:
>> ....this is beginning to look suspiciously like the "Namespace"  
>> discussion with respect to resource-priority, isn't it?
>>
>> After thinking about this some more, I feel even more strongly along  
>> the lines Jon Peterson suggested - don't put this into SIP; instead  
>> deal with it as a role assertion through a SAML document provided as  
>> part of the (enhanced) identity work when we get around to it.
>>
>> This comprises yet another use case for SAML (besides delegation)  
>> which may argue for our being more aggressive about moving this  
>> forward right on the heels of the identity work. Anyone want to  
>> tackle this with an i.d.?
>
> How would this new ID idea be different than:
> http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-01.txt ?
>
> The above is the answer doc to the requirements ID we authors have  
> been kinda dragging out feet about revving at:
> http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-trait-authz 
> -00.txt
> but we think is essentially done once revved.
>
I agree.

>
>> Dave.
>
>
> cheers,
> James
>
>                                *******************
>                 Truth is not to be argued... it is to be presented
>
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran@cisco.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec  2 03:00:16 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17258
	for <sip-web-archive@ietf.org>; Thu, 2 Dec 2004 03:00:15 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZlyP-0002zc-On
	for sip-web-archive@ietf.org; Thu, 02 Dec 2004 03:05:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZlYL-0008L1-AO; Thu, 02 Dec 2004 02:39:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZktq-0000uQ-UI; Thu, 02 Dec 2004 01:57:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27082;
	Thu, 2 Dec 2004 01:57:09 -0500 (EST)
Received: from mail4.telekom.de ([195.243.210.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZkzK-0001ZN-5B; Thu, 02 Dec 2004 02:02:50 -0500
Received: from g8pbq.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP;
	Thu, 2 Dec 2004 07:56:19 +0100
Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <X53HCFZ8>; Thu, 2 Dec 2004 07:56:35 +0100
Message-Id: <E7666D92C64C2845AEF12636FF94F952F97522@S4DE8PSAAGQ.blf.telekom.de>
From: "Jesske, R" <R.Jesske@t-com.net>
To: oran@cisco.com
Subject: AW: [Sip] AW:  Calling Party's Category
Date: Thu, 2 Dec 2004 07:56:33 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Content-Transfer-Encoding: quoted-printable
Cc: iptel@ietf.org, sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7
Content-Transfer-Encoding: quoted-printable

The CPC in ITU-T/ETSI and the OLI in ANSI (Originating Line =
Identification) are well defined code points. I think IETF is also able =
to restrict definitions of code points used for routing aspects (Or Im =
Wrong?)

more comments in the text

Roland

> -----Urspr=FCngliche Nachricht-----
> Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]Im Auftrag von
> David R Oran
> Gesendet: Mittwoch, 1. Dezember 2004 15:46
> An: Jesske, Roland
> Cc: list iptel; 'sip@ietf.org'
> Betreff: Re: [Sip] AW: Calling Party's Category
>=20
>=20
> Just curious - what does it take to get a CPC code point=20
> allocated? If=20
> the IETF is to put this into SIP somehow, this issue will undoubtedly =

> come up (as it did in spades for ENUM).
>=20
> So, let's assume I want to have a CPC called "Bordello", with the=20
> following characteristics
> - Calls to normal destinations are allowed and billed to the=20
> associated=20
> subscriber account
> - Calls to the police are blocked
> - Incoming calls are diverted to a sexy autoattendant.
> - Calls to residences of known customers (provisioned by bordello=20
> owner) are anonymized, or alternatively obfuscated with a location=20
> header showing the origin is elsewhere.

If I use a P-Asserted-ID (with regard to 3323+3323 a trust model is =
defined) the CPC will be provided by the network and should be secure =
and as I said this element is also used for routing purposes so the =
definition of new code points should be restricted.=20
The concept described within draft-mahy-iptel-cpc-00 is to add the CPC =
as an element within the URI. From my point of view it could be also a =
normal header or P-header.
We see the need of such kind of mechanism and others too.
>=20
> The following questions obtain:
> a) who allocates the "Bordello" codepoint?
> b) what is the scope of the allocation?
> c) where are the semantics documented (e.g. RFC, part of=20
> registration,=20
> etc.)
> d) how does it interact with other call handling related functions?
>=20
> this is beginning to look suspiciously like the "Namespace"=20
> discussion=20
> with respect to resource-priority, isn't it?

No. draft-ietf-sip-resource-priority-05 is addressing priority =
services. CPC is addressing other issues.

>=20
> After thinking about this some more, I feel even more strongly along=20
> the lines Jon Peterson suggested - don't put this into SIP; instead=20
> deal with it as a role assertion through a SAML document provided as=20
> part of the (enhanced) identity work when we get around to it.

This could be used for billing services but not for routing from my =
understanding.

>=20
> This comprises yet another use case for SAML (besides=20
> delegation) which=20
> may argue for our being more aggressive about moving this=20
> forward right=20
> on the heels of the identity work. Anyone want to tackle this with an =

> i.d.?
>=20
> Dave.
>=20
> On Dec 1, 2004, at 1:27 AM, Jesske, R wrote:
>=20
> > Dear Tom, all,
> > I see there are several questions with regard to the CPC.=20
> Our approach=20
> > is to use it for billing, charge info and routing purposes.
> >
> > Payphone:
> > 1. Payphone Calls are routed in an other manner than normal calls
> > 2. Payphone Calls are billed differently compared with normal calls
> > 3. The charge information shown to the user of the payphone is an=20
> > other than for normal once
> > 4. Based on the CPC a blocking of numbers (e.G premium rate=20
> or special=20
> > destinations) can be performed
> > 5. Special accounting mechanisms for free phone numbers are =
possible
> >
> > A question was how to perform security and trust. Using the=20
> CPC within=20
> > the P-Asserted-ID makes this information trusted. The UA can advice =

> > with the P-Preferred-ID that the SIP Proxy should use the=20
> proposed URI=20
> > as P-Asserted-ID. But Proxy verifies this information. If the 
> > Information in the Hint is not correct the dialog will be=20
> candled or=20
> > the stored ID will be provided by the network.
> >
> > Best Regards
> >
> > Roland
> >
> >
> >
> >
> > -----Urspr=FCngliche Nachricht-----
> > Von: Tom Taylor [mailto:taylor@nortelnetworks.com]
> > Gesendet: Dienstag, 30. November 2004 19:51
> > An: Nguyen, An
> > Cc: iptel@ietf.org; sipping@ietf.org; Jesske, Roland
> > Betreff: Re: [Iptel] Calling Party's Category
> >
> >
> > Jonathan, I hope I am stating this correctly.
> >
> > The Chair's proposal at the meeting was that this draft be dropped, =

> > because with
> > SIP-T defined, there is no need to define other means in=20
> SIP to carry=20
> > signalling
> > destined specifically to the PSTN.  However, if use cases can be=20
> > provided which
> > demonstrate a requirement to be met in the pure SIP=20
> environment, work=20
> > can be done
> > (probably in SIPPING) to meet those requirements.
> >
> > Nguyen, An wrote:
> >> Mr. Taylor;
> >>
> >> I am just curious ... What is the status of the Internet Draft?
> >>
> >> An
> >>
> >>
> > [snip]
> >
> > --=20
> > Tom Taylor
> > Carrier VoIP Standards Development
> > Nortel Networks
> > Phone +1 613 763 1496  (ESN 393-1496)
> > E-mail: taylor@nortelnetworks.com
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
> David R. Oran
> Cisco Fellow
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720 USA
> Tel: +1 978 264 2048
> Email: oran@cisco.com
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec  2 22:04:49 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01971
	for <sip-web-archive@ietf.org>; Thu, 2 Dec 2004 22:04:49 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ca3qE-0007Rw-58
	for sip-web-archive@ietf.org; Thu, 02 Dec 2004 22:10:42 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ca0Td-0005Xd-GF; Thu, 02 Dec 2004 18:35:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CZzuO-0008O5-9z
	for sip@megatron.ietf.org; Thu, 02 Dec 2004 17:58:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10356
	for <sip@ietf.org>; Thu, 2 Dec 2004 17:58:41 -0500 (EST)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZzzz-0001gv-Mv
	for sip@ietf.org; Thu, 02 Dec 2004 18:04:32 -0500
Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id iB2Mw8j05114
	for <sip@ietf.org>; Thu, 2 Dec 2004 17:58:08 -0500 (EST)
Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <XQM2TKRP>; Thu, 2 Dec 2004 17:58:08 -0500
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB05312516@zrc2hxm1.corp.nortel.com>
From: "Mary Barnes" <mary.barnes@nortelnetworks.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Thu, 2 Dec 2004 17:57:59 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Subject: [Sip] History-Info: Summary of WGLC comments
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0316746666=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 225414c974e0d6437992164e91287a51

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0316746666==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4D8C2.5E87B757"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4D8C2.5E87B757
Content-Type: text/plain

Hi all,

WGLC for the draft-ietf-sip-history-info-04 ended on Nov 29th; the following
summarizes the comments received during that review period.  Some of them
were posted on the WG mailing list, whereas others were sent as individual
emails as they were primarily of editorial nature.  I have annotated the
sources below.

- Section 3, 3rd paragraph:  Change the phrase "The History-Info header is
added to a Request when a new request is created by a UAC or Proxy, or when
the target of a request is changed." to "The History-Info header is added to
a Request when a new request is created by a UAC or forwarded by a
Proxy...."  (this error was introduced in the rewrite of the -01 version of
the draft) [SP - individual email Nov. 18]

- Section 4.3.1:  Add text similar to that added for handling the reason in
section 4.3.3.1.2 (i.e .the UAC must also properly handle the Reason header
in responses).  [JRE-individual email Nov. 15]

- Section 4.3.3.1.1, lst paragraph, last statment:  change "...the proxy
MUST remove any hi-entry(s) prior to forwarding."
to:
"...the proxy SHOULD remove any hi-entry(s) prior to forwarding, depending
upon local policy and whether the proxy might know apriori that it can rely
on a downstream privacy service to apply the requested privacy." [WG mailing
list - conclusion posted on Nov. 17]

- Section 4.3.3.1.2, last paragraph : a "is" shall be added between "it" and
"associated" in the phrase "as it associated with the hi-targeted-to-uri
that has been retargeted, since it reflects the reason why the Request to
that specific URI was not successful"  [SP - individual email Nov. 18]

- Section 4.5 examples: 
  - Fix indexing (2 should have been 1.1, which affects the whole series).
[WG mailing list response to TS posted on Nov. 3rd]
  - Fix the 480 "timeouts" which should be 408s (note this error was
introduced with changes made in this section in the 03 version. [NC-
individual email Oct 31)
  - Fix missing " on the "Busy Here" on the INVITE to UA5 in 4.5.1. [NC-
individual email Oct 31]

I plan on submitting the updated draft by the end of the week, so that it's
ready for IETF LC/IESG review.  

Thanks for all who reviewed and commented on this draft.

Mary.


------_=_NextPart_001_01C4D8C2.5E87B757
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>History-Info: Summary of WGLC comments</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi all,</FONT>
</P>

<P><FONT SIZE=3D2>WGLC for the draft-ietf-sip-history-info-04 ended on =
Nov 29th; the following summarizes the comments received during that =
review period.&nbsp; Some of them were posted on the WG mailing list, =
whereas others were sent as individual emails as they were primarily of =
editorial nature.&nbsp; I have annotated the sources below.</FONT></P>

<P><FONT SIZE=3D2>- Section 3, 3rd paragraph:&nbsp; Change the phrase =
&quot;The History-Info header is added to a Request when a new request =
is created by a UAC or Proxy, or when the target of a request is =
changed.&quot; to &quot;The History-Info header is added to a Request =
when a new request is created by a UAC or forwarded by a =
Proxy....&quot;&nbsp; (this error was introduced in the rewrite of the =
-01 version of the draft) [SP - individual email Nov. 18]</FONT></P>

<P><FONT SIZE=3D2>- Section 4.3.1:&nbsp; Add text similar to that added =
for handling the reason in section 4.3.3.1.2 (i.e .the UAC must also =
properly handle the Reason header in responses).&nbsp; [JRE-individual =
email Nov. 15]</FONT></P>

<P><FONT SIZE=3D2>- Section 4.3.3.1.1, lst paragraph, last =
statment:&nbsp; change &quot;...the proxy MUST remove any hi-entry(s) =
prior to forwarding.&quot;</FONT></P>

<P><FONT SIZE=3D2>to:</FONT>
<BR><FONT SIZE=3D2>&quot;...the proxy SHOULD remove any hi-entry(s) =
prior to forwarding, depending upon local policy and whether the proxy =
might know apriori that it can rely on a downstream privacy service to =
apply the requested privacy.&quot; [WG mailing list - conclusion posted =
on Nov. 17]</FONT></P>

<P><FONT SIZE=3D2>- Section 4.3.3.1.2, last paragraph : a =
&quot;is&quot; shall be added between &quot;it&quot; and =
&quot;associated&quot; in the phrase &quot;as it associated with the =
hi-targeted-to-uri that has been retargeted, since it reflects the =
reason why the Request to that specific URI was not =
successful&quot;&nbsp; [SP - individual email Nov. 18]</FONT></P>

<P><FONT SIZE=3D2>- Section 4.5 examples: </FONT>
<BR><FONT SIZE=3D2>&nbsp; - Fix indexing (2 should have been 1.1, which =
affects the whole series). [WG mailing list response to TS posted on =
Nov. 3rd]</FONT></P>

<P><FONT SIZE=3D2>&nbsp; - Fix the 480 &quot;timeouts&quot; which =
should be 408s (note this error was introduced with changes made in =
this section in the 03 version. [NC- individual email Oct =
31)</FONT></P>

<P><FONT SIZE=3D2>&nbsp; - Fix missing &quot; on the &quot;Busy =
Here&quot; on the INVITE to UA5 in 4.5.1. [NC- individual email Oct =
31]</FONT>
</P>

<P><FONT SIZE=3D2>I plan on submitting the updated draft by the end of =
the week, so that it's ready for IETF LC/IESG review.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Thanks for all who reviewed and commented on this =
draft.</FONT>
</P>

<P><FONT SIZE=3D2>Mary.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4D8C2.5E87B757--


--===============0316746666==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0316746666==--



From sip-bounces@ietf.org  Fri Dec  3 15:08:30 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01299
	for <sip-web-archive@ietf.org>; Fri, 3 Dec 2004 15:08:30 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaJp1-00036s-RV
	for sip-web-archive@ietf.org; Fri, 03 Dec 2004 15:14:32 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CaJYo-0004Oj-3C; Fri, 03 Dec 2004 14:57:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaJ9j-00020K-TM
	for sip@megatron.ietf.org; Fri, 03 Dec 2004 14:31:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25661
	for <sip@ietf.org>; Fri, 3 Dec 2004 14:31:50 -0500 (EST)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaJFV-0001OZ-PV
	for sip@ietf.org; Fri, 03 Dec 2004 14:37:51 -0500
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id iB3JVGi24625; Fri, 3 Dec 2004 14:31:17 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <YFGW65KC>; Fri, 3 Dec 2004 14:31:17 -0500
Message-ID: <851CB96E7B97D2119A900000F8713341029E0723@zcrrd001.cala.nortel.com>
From: "Mariano-Julio Stokle" <mstokle@nortelnetworks.com>
To: sip@ietf.org, jdrosen@cisco.com
Date: Fri, 3 Dec 2004 14:31:08 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Subject: [Sip] draft-ietf-sip-gruu-02
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0821296337=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0821296337==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4D96E.A369F83C"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4D96E.A369F83C
Content-Type: text/plain

Hi,
        I noted in this draft an error in page 23, it says:
 
"The response, message 24, is shown below:
 

   REGISTER sip:example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbbd
   From: Callee <sip:callee@example.com>;tag=ha8d777f3
   To: Callee <sip:callee@example.com>;tag=asd7salll
   Call-ID: hf8asxzff8s7g@192.0.2.2
   CSeq: 4 REGISTER
   Contact: <sip:callee@192.0.2.2>
     ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
     ;expires=3600
"
 
 
It is clearly not a response, in fact it is the request referenced as
message 23. 

Mariano Stokle

------_=_NextPart_001_01C4D96E.A369F83C
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.2">
<TITLE>draft-ietf-sip-gruu-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi,</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I noted in this draft an error in page 23, it says:</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>&quot;The response, message 24, is shown below:</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; REGISTER sip:example.com SIP/2.0</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Via: SIP/2.0/UDP 192.0.2.2;branch=z9hG4bKnasbbd</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; From: Callee &lt;sip:callee@example.com&gt;;tag=ha8d777f3</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; To: Callee &lt;sip:callee@example.com&gt;;tag=asd7salll</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Call-ID: hf8asxzff8s7g@192.0.2.2</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; CSeq: 4 REGISTER</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Contact: &lt;sip:callee@192.0.2.2&gt;</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; ;+sip.instance=&quot;&lt;urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6&gt;&quot;</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; ;expires=3600</FONT>
<BR><FONT SIZE=2>&quot;</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>It is clearly not a response, in fact it is the request referenced as message 23. </FONT>
</P>

<P><FONT SIZE=2>Mariano Stokle</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4D96E.A369F83C--


--===============0821296337==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0821296337==--



From sip-bounces@ietf.org  Fri Dec  3 17:47:39 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15115
	for <sip-web-archive@ietf.org>; Fri, 3 Dec 2004 17:47:39 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaMJ3-0007lR-W7
	for sip-web-archive@ietf.org; Fri, 03 Dec 2004 17:53:43 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CaLnS-0003tZ-Da; Fri, 03 Dec 2004 17:21:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaLRv-0002F8-S4
	for sip@megatron.ietf.org; Fri, 03 Dec 2004 16:58:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06506
	for <sip@ietf.org>; Fri, 3 Dec 2004 16:05:23 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaKi1-0004yB-W3
	for sip@ietf.org; Fri, 03 Dec 2004 16:11:25 -0500
Received: from [63.110.3.236] ([64.100.183.236]) (authenticated bits=0)
	by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iB3L63np007435
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 3 Dec 2004 15:06:05 -0600
In-Reply-To: <419C0973.9020609@netscape.net>
References: <AD924AD1-2E78-11D9-9263-000D93C60450@ekabal.com>
	<419C0973.9020609@netscape.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <09D44C51-456F-11D9-B529-000D93594350@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Date: Fri, 3 Dec 2004 15:05:19 -0600
To: Bert Culpepper <bertculpepper@netscape.net>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
Subject: [Sip] Wrap-up of  WGLC for App Interact
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit


I believe we started WGLC for App Interact on November 4.

Bert made some reasonable-looking comments on November 17 that I didn't 
see any response to.

Does anybody else have anything to say about this draft?

--
Dean
SIP WG co-chair.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Sat Dec  4 01:55:44 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18744
	for <sip-web-archive@ietf.org>; Sat, 4 Dec 2004 01:55:43 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaTvS-0000z5-OZ
	for sip-web-archive@ietf.org; Sat, 04 Dec 2004 02:01:51 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CaTkQ-0000ai-Vo; Sat, 04 Dec 2004 01:50:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaTaC-0005v8-Cp
	for sip@megatron.ietf.org; Sat, 04 Dec 2004 01:39:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17677
	for <sip@ietf.org>; Sat, 4 Dec 2004 01:39:51 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaTg5-0000ey-MI
	for sip@ietf.org; Sat, 04 Dec 2004 01:45:58 -0500
Received: from sj-core-4.cisco.com (171.68.223.138)
	by sj-iport-4.cisco.com with ESMTP; 03 Dec 2004 22:38:39 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iB46dUvH004427;
	Fri, 3 Dec 2004 22:39:30 -0800 (PST)
Received: from [192.168.1.102] (che-vpn-cluster-2-5.cisco.com [10.86.242.5])
	by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGC78375;
	Fri, 3 Dec 2004 22:39:29 -0800 (PST)
Message-ID: <41B134E3.4090502@cisco.com>
Date: Fri, 03 Dec 2004 22:54:11 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: privacy without b2bua, was: Re: third alternative (was RE: [Sip]
	RE: Identity after reinvite)
References: <24EAE5D4448B9D4592C6D234CBEBD597089963@stntexch03.cis.neustar.com>
	<41A44526.3080703@cisco.com> <41A49BC2.4020908@cisco.com>
In-Reply-To: <41A49BC2.4020908@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: 7bit
Cc: "'Cullen Jennings'" <fluffy@cisco.com>, "'sip@ietf.org'" <sip@ietf.org>,
        "'David R Oran'" <oran@cisco.com>,
        "Peterson, Jon" <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit

inline.

Paul Kyzivat wrote:

> Jonathan - inline.
> 
>     Paul
> 
> Jonathan Rosenberg wrote:
> 
>>
>>> RFC3323 is about due for an update, I think, because the major functions
>>> that it provides can be performed without a B2BUA, thanks to new SIP
>>> mechanisms like GRUUs and session-policy. So while I agree that an
>>> anonymization service is the right approach to this problem, these 
>>> days I
>>> think you can probably build an anonymization service without building a
>>> B2BUA.
>>
>>
>> I believe this is probably true. Here's how I think it'd work:
>>
>> A client that wants to make an anonymous call contacts a TURN server 
>> providing anonymization services. That server provides the client with 
>> IP addresses and ports that it can use in its Via, contact, and SDP. 
>> The From field is anonymized. A privacy header is inserted. The 
>> request is sent via the TURN server to the user's outbound proxy. That 
>> proxy can still authenticate the client, and even insert an identity 
>> header that at least vouches that the client is a legit client that is 
>> just anonymous.
> 
> 
> While I buy the approach, I don't think what you are describing is a 
> TURN server. It is a combination of a TURN server and a SIP 
> anonymization server. And I don't even see how this can be viewed as one 
> thing. The client has to contact a TURN server from the address/port it 
> intends to use for media. 

Nothing about TURN is media specific. It gives you an IP/port on which 
you can get packets. Why not use it to get an IP/port for receiving SIP 
packets, and populate that into my via/Contact?


> For multiple media streams it needs to do this 
> multiple times from different source ports. It also has to contact the 
> sip anonymization server to set up the sip anonymization. Then it can 
> proceed as you describe.

I'm suggesting that the TURN server could provide the sip client with 
the IP/port it needs to do its own sip anonymization.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Sat Dec  4 02:02:19 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21513
	for <sip-web-archive@ietf.org>; Sat, 4 Dec 2004 02:02:19 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaU1q-00019O-0k
	for sip-web-archive@ietf.org; Sat, 04 Dec 2004 02:08:26 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CaTkS-0000ay-Rv; Sat, 04 Dec 2004 01:50:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaTaT-0005wD-ID
	for sip@megatron.ietf.org; Sat, 04 Dec 2004 01:40:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17701
	for <sip@ietf.org>; Sat, 4 Dec 2004 01:40:08 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaTgK-0000f9-R7 for sip@ietf.org; Sat, 04 Dec 2004 01:46:15 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 03 Dec 2004 22:44:54 -0800
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iB46dXAJ016302;
	Fri, 3 Dec 2004 22:39:33 -0800 (PST)
Received: from [192.168.1.102] (che-vpn-cluster-2-5.cisco.com [10.86.242.5])
	by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AGC78378;
	Fri, 3 Dec 2004 22:39:31 -0800 (PST)
Message-ID: <41B135A5.1040208@cisco.com>
Date: Fri, 03 Dec 2004 22:57:25 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] PING/PONG
References: <CD9775120D600F43B9C50329395E9DB64F321F@ivor.citel.com>
	<13719E43-3D96-11D9-93B0-000D93326732@nostrum.com>
	<41A43E4D.8020102@cisco.com>
	<59BC20AE-3E26-11D9-93B0-000D93326732@nostrum.com>
In-Reply-To: <59BC20AE-3E26-11D9-93B0-000D93326732@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, Christian Stredicke <Christian.Stredicke@snom.de>,
        Steve Langstaff <steve.langstaff@citel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit

inline.

Robert Sparks wrote:

>>
>>> Endpoints behind the things we are wanting to do this refresh things 
>>> to can be signaling
>>> directly with endpoints that aren't (a service provider could let 
>>> people talk to voice-mail
>>> or conference servers directly).
>>
>>
>> I don't see how that practically works in the presence of nat. If you 
>> are using tcp/tls, the thing to which you have a connection open is 
>> the only place from which you can get subsequent requests. Thus, if I 
>> make a call that lands on a voicemail server, the proxy holding my 
>> tcp/tls connection has to be on the signaling path, or it just won't 
>> work.
> 
> 
> If I can establish a tcp/tls connection to that voicemail server, then 
> subsequent requests from it can
> come back down that connection assuming we can keep it alive.

My point is, there may not (indeed, won't be) a connection to that thing 
in the first place. It would need to be established only after the call 
setup is complete. How would the client know to do that? You also have a 
race condition, whereby even if the client knew to do this, a sip 
request could arrive from the voicemail server before the client can 
establish the connection. I'm just not seeing the benefit here.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Sat Dec  4 03:22:41 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09632
	for <sip-web-archive@ietf.org>; Sat, 4 Dec 2004 03:22:40 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaVHd-0002j8-4k
	for sip-web-archive@ietf.org; Sat, 04 Dec 2004 03:28:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CaV35-0001Ii-HI; Sat, 04 Dec 2004 03:13:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaUwA-00080r-GI
	for sip@megatron.ietf.org; Sat, 04 Dec 2004 03:06:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08527
	for <sip@ietf.org>; Sat, 4 Dec 2004 03:06:36 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaV23-0002R1-7W for sip@ietf.org; Sat, 04 Dec 2004 03:12:44 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 04 Dec 2004 00:11:24 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iB4860AL000504;
	Sat, 4 Dec 2004 00:06:03 -0800 (PST)
Received: from [10.0.1.3] (sjc-vpn4-119.cisco.com [10.21.80.119])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUM41987;
	Sat, 4 Dec 2004 00:05:59 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Fri, 03 Dec 2004 16:33:54 -0800
Subject: Re: third alternative (was RE: [Sip] RE: Identity after reinvite)
From: Cullen Jennings <fluffy@cisco.com>
To: Jon Peterson <jon.peterson@neustar.biz>,
        Jonathan Rosenberg <jdrosen@cisco.com>
Message-ID: <BDD645F2.1CDA1%fluffy@cisco.com>
In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD59708994C@stntexch03.cis.neustar.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 1.4 (+)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Paul H Kyzivat <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 1.4 (+)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit

On 11/17/04 11:04 PM, "Peterson, Jon" <jon.peterson@neustar.biz> wrote:

> For me, this comes down to a very, very simple case: Alice sends a call to
> Bob, and then in the middle of the call, she gets a BYE request from Edgar.
> Does Alice accept the BYE or not?

This example pretty much summarizes the whole issue for me. I'm in full
agreement with Jon on this stuff. If I ever get a chance, I plan to update
the the connected party draft to use this example. 



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Sat Dec  4 03:23:48 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09697
	for <sip-web-archive@ietf.org>; Sat, 4 Dec 2004 03:23:48 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaVIi-0002kS-Cr
	for sip-web-archive@ietf.org; Sat, 04 Dec 2004 03:29:56 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CaV3B-0001JJ-H1; Sat, 04 Dec 2004 03:13:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaUwA-00080s-GH
	for sip@megatron.ietf.org; Sat, 04 Dec 2004 03:06:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08533
	for <sip@ietf.org>; Sat, 4 Dec 2004 03:06:36 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaV23-0002R2-C4 for sip@ietf.org; Sat, 04 Dec 2004 03:12:44 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-1.cisco.com with ESMTP; 04 Dec 2004 00:12:55 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iB4863AJ000516;
	Sat, 4 Dec 2004 00:06:04 -0800 (PST)
Received: from [10.0.1.3] (sjc-vpn4-119.cisco.com [10.21.80.119])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUM41991;
	Sat, 4 Dec 2004 00:06:01 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Fri, 03 Dec 2004 18:46:12 -0800
Subject: Re: privacy without b2bua, was: Re: third alternative (was RE:
	[Sip] RE: Identity after reinvite)
From: Cullen Jennings <fluffy@cisco.com>
To: Jonathan Rosenberg <jdrosen@cisco.com>,
        Jon Peterson <jon.peterson@neustar.biz>
Message-ID: <BDD664F4.1CD92%fluffy@cisco.com>
In-Reply-To: <41A44526.3080703@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Paul H Kyzivat <pkyzivat@cisco.com>,
        Dave Oran <oran@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: 7bit


I agree with the direction this is going but I think the anonymization
services needs to be a bit more complex than a simple TURN server. A simple
TURN server would make it too easy to do statistical timing analysis of the
incoming and outgoing traffic and form the connections about who is taking
to who. Of course this is always an issue of all anonymization servers - a
service with only one user that is known is not all that anonymous. Anyways,
I think we could easily work up to something based along the lines of the
approach described below that is not  too complex to describe and is
significantly stronger than a simple relay.


On 11/24/04 12:24 AM, "Jonathan Rosenberg" <jdrosen@cisco.com> wrote:

> 
> 
> Peterson, Jon wrote:
> 
>> A few notes on the "Monica property": as RFC3323 suggests, I think that some
>> sort of anonymization service, which could be instantiated by a B2BUA, is an
>> appropriate way to conceal the identity of a called or calling party. What
>> scares me a little is the way people suggest that retargeting, as opposed to
>> redirection, can inherently be expected to provide privacy. When I register
>> a contact, I can't always guarantee that the location service in question
>> will be used exclusively for retargeting rather than redirection; moreover,
>> the revelation of the target Request-URI to the caller is not the only way
>> that the caller can learn who the connected-party is: contact headers of new
>> requests in the backwards direction of the dialog, SDP in a 200 OK, and so
>> on, are information leaks that are not addressed at all by retargeting, but
>> would be addressed by an anonymization service.
>> 
>> RFC3323 is about due for an update, I think, because the major functions
>> that it provides can be performed without a B2BUA, thanks to new SIP
>> mechanisms like GRUUs and session-policy. So while I agree that an
>> anonymization service is the right approach to this problem, these days I
>> think you can probably build an anonymization service without building a
>> B2BUA.
> 
> I believe this is probably true. Here's how I think it'd work:
> 
> A client that wants to make an anonymous call contacts a TURN server
> providing anonymization services. That server provides the client with
> IP addresses and ports that it can use in its Via, contact, and SDP. The
>  From field is anonymized. A privacy header is inserted. The request is
> sent via the TURN server to the user's outbound proxy. That proxy can
> still authenticate the client, and even insert an identity header that
> at least vouches that the client is a legit client that is just anonymous.
> 
> The provider of the anonymization server (turn in this case) can be
> completely decoupled from the sip provider. That provides an excellent
> level of anonymity compared to even a b2bua. The b2bua approach would
> still allow the recipient to trace the IP address in the SDP and Contact
> to the particular provider; this might not be sufficient (I don't recall
> off hand if rfc3323 discusses this problme).
> 
> It also means that there is no need to signal things like header or
> media level privacy. The client simply chooses to obfuscate (using the
> learned turn addresses) whatever fields it wishes to anonymize. This has
> the impact of simplifying the privacy spec significantly. Indeed, it
> would seem that it is hardly needed at all...
> 
> -Jonathan R.
> 



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Sat Dec  4 08:16:14 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28007
	for <sip-web-archive@ietf.org>; Sat, 4 Dec 2004 08:16:14 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CaZrl-0000UV-45
	for sip-web-archive@ietf.org; Sat, 04 Dec 2004 08:22:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CaZi9-0003YZ-0E; Sat, 04 Dec 2004 08:12:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CaZVy-0008JZ-JT
	for sip@megatron.ietf.org; Sat, 04 Dec 2004 07:59:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26323
	for <sip@ietf.org>; Sat, 4 Dec 2004 07:59:51 -0500 (EST)
Received: from viefep13-int.chello.at ([213.46.255.15])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaZbi-0008RE-QS
	for sip@ietf.org; Sat, 04 Dec 2004 08:06:01 -0500
Received: from [192.168.2.21] (really [84.114.158.201])
	by viefep13-int.chello.at
	(InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP
	id <20041204125901.JAIE12679.viefep13-int.chello.at@[192.168.2.21]>;
	Sat, 4 Dec 2004 13:59:01 +0100
Message-ID: <41B1B496.9080904@pernau.at>
Date: Sat, 04 Dec 2004 13:59:02 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anil Bollineni <ABollineni@juniper.net>
References: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FE4@hadron.jnpr.net>
In-Reply-To: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FE4@hadron.jnpr.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu
Subject: [Sip] Re: [Sip-implementors] OPTIONS outside dialog
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit

You should response with the some response code as this mould have been 
an INVITE - e.g. 200 OK if everything is fine, "buse here" if the phone 
is busy...

You hsould also include an SDP body to indicate the possible codecs.

klaus

Anil Bollineni wrote:

> Hi,
> 
>     Assume OPTIONS comes outside dialog, what are the possible responses
> that are for OPTIONS, assume these are the same responses for any
> request as defined in RFC 3261. Please clarify.
> 
>  
> 
> Thanks in advance,
> 
> Anil
> 
>  
> 
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec  6 08:38:43 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14201
	for <sip-web-archive@ietf.org>; Mon, 6 Dec 2004 08:38:43 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbJB1-0005LE-5P
	for sip-web-archive@ietf.org; Mon, 06 Dec 2004 08:45:19 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbJ2n-0002ze-U7; Mon, 06 Dec 2004 08:36:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbIxY-00022X-Mz
	for sip@megatron.ietf.org; Mon, 06 Dec 2004 08:31:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13683
	for <sip@ietf.org>; Mon, 6 Dec 2004 08:31:23 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbJ3u-0005BT-46 for sip@ietf.org; Mon, 06 Dec 2004 08:37:59 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-1.cisco.com with ESMTP; 06 Dec 2004 05:38:04 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iB6DUhAJ002447;
	Mon, 6 Dec 2004 05:30:44 -0800 (PST)
Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR)
	with ESMTP id ANM24533; Mon, 6 Dec 2004 08:30:42 -0500 (EST)
Message-ID: <41B45F02.3040906@cisco.com>
Date: Mon, 06 Dec 2004 08:30:42 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: privacy without b2bua, was: Re: third alternative (was RE: [Sip]
	RE: Identity after reinvite)
References: <24EAE5D4448B9D4592C6D234CBEBD597089963@stntexch03.cis.neustar.com>
	<41A44526.3080703@cisco.com> <41A49BC2.4020908@cisco.com>
	<41B134E3.4090502@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: "'Cullen Jennings'" <fluffy@cisco.com>, "'sip@ietf.org'" <sip@ietf.org>,
        "'David R Oran'" <oran@cisco.com>,
        "Peterson, Jon" <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:
> 
> Paul Kyzivat wrote:
>>
 >> While I buy the approach, I don't think what you are describing is a
 >> TURN server. It is a combination of a TURN server and a SIP
 >> anonymization server. And I don't even see how this can be viewed as
 >> one thing. The client has to contact a TURN server from the
 >> address/port it intends to use for media.
 >
 > Nothing about TURN is media specific. It gives you an IP/port on which
 > you can get packets. Why not use it to get an IP/port for receiving
 > SIP packets, and populate that into my via/Contact?
 >
 >> For multiple media streams it needs to do this multiple times from
 >> different source ports. It also has to contact the sip anonymization
 >> server to set up the sip anonymization. Then it can proceed as you
 >> describe.
 >
 > I'm suggesting that the TURN server could provide the sip client with
 > the IP/port it needs to do its own sip anonymization.

OK. I think I entirely misinterpretted what you were saying:

>>> I believe this is probably true. Here's how I think it'd work:
>>>
>>> A client that wants to make an anonymous call contacts a TURN server 
>>> providing anonymization services. That server provides the client 
>>> with IP addresses and ports that it can use in its Via, contact, and 
>>> SDP.

With the understanding that it will take multiple requests to the TURN 
server to accumulate all of these addresses.

 >>> The From field is anonymized. A privacy header is inserted.

By the client.  (I had assumed you meant by the server.)

 >>> The
>>> request is sent via the TURN server to the user's outbound proxy. 
>>> That proxy can still authenticate the client, and even insert an 
>>> identity header that at least vouches that the client is a legit 
>>> client that is just anonymous.

OK. This now sounds plausible to me.

	Paul


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec  6 09:59:57 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18761
	for <sip-web-archive@ietf.org>; Mon, 6 Dec 2004 09:59:57 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbKRd-0006rR-TB
	for sip-web-archive@ietf.org; Mon, 06 Dec 2004 10:06:35 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbKGE-00054c-F9; Mon, 06 Dec 2004 09:54:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbKDR-0004hw-SH
	for sip@megatron.ietf.org; Mon, 06 Dec 2004 09:51:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18390
	for <sip@ietf.org>; Mon, 6 Dec 2004 09:51:52 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbKJn-0006is-Oe
	for sip@ietf.org; Mon, 06 Dec 2004 09:58:29 -0500
Received: from [192.168.1.216] (c-24-1-66-77.client.comcast.net [24.1.66.77])
	(authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iB6EpYOM054232
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Mon, 6 Dec 2004 08:51:40 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <41B135A5.1040208@cisco.com>
References: <CD9775120D600F43B9C50329395E9DB64F321F@ivor.citel.com>
	<13719E43-3D96-11D9-93B0-000D93326732@nostrum.com>
	<41A43E4D.8020102@cisco.com>
	<59BC20AE-3E26-11D9-93B0-000D93326732@nostrum.com>
	<41B135A5.1040208@cisco.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <53A35690-4796-11D9-8F23-000D93326732@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] PING/PONG
Date: Mon, 6 Dec 2004 08:51:35 -0600
To: Jonathan Rosenberg <jdrosen@cisco.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, Christian Stredicke <Christian.Stredicke@snom.de>,
        Steve Langstaff <steve.langstaff@citel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Content-Transfer-Encoding: 7bit

I hope we're talking past each other at this point.

You seem to be proposing that I would _never_ open a connection with 
anything but
one proxy, even if I had network visibility to something else and the 
knowledge that
I wanted to talk to it.

I'm saying that if I want to have a dialog with something that I can 
reach (but it can't
open a connection to me), that I want to open a connection to it and 
for the duration
of that dialog, keep the connection alive. My original point is that I 
want to use the
same mechanism we define for keeping a connection to a proxy alive.

I think maybe you're only seeing the "tried to place a call and it 
ended up on some
random voicemail server" use case in your response below. Look at it 
from a
retrieving voicemail point of view. Then consider other services (like 
a presence server)
I might like to use, perhaps from a third party provider.

RjS


On Dec 3, 2004, at 9:57 PM, Jonathan Rosenberg wrote:

> inline.
>
> Robert Sparks wrote:
>
>>>
>>>> Endpoints behind the things we are wanting to do this refresh 
>>>> things to can be signaling
>>>> directly with endpoints that aren't (a service provider could let 
>>>> people talk to voice-mail
>>>> or conference servers directly).
>>>
>>>
>>> I don't see how that practically works in the presence of nat. If 
>>> you are using tcp/tls, the thing to which you have a connection open 
>>> is the only place from which you can get subsequent requests. Thus, 
>>> if I make a call that lands on a voicemail server, the proxy holding 
>>> my tcp/tls connection has to be on the signaling path, or it just 
>>> won't work.
>> If I can establish a tcp/tls connection to that voicemail server, 
>> then subsequent requests from it can
>> come back down that connection assuming we can keep it alive.
>
> My point is, there may not (indeed, won't be) a connection to that 
> thing in the first place. It would need to be established only after 
> the call setup is complete. How would the client know to do that? You 
> also have a race condition, whereby even if the client knew to do 
> this, a sip request could arrive from the voicemail server before the 
> client can establish the connection. I'm just not seeing the benefit 
> here.
>
> -Jonathan R.
>
>
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> jdrosen@cisco.com                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec  6 16:54:52 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28975
	for <sip-web-archive@ietf.org>; Mon, 6 Dec 2004 16:54:52 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbQvF-0000G7-6J
	for sip-web-archive@ietf.org; Mon, 06 Dec 2004 17:01:34 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbQkn-0001gB-H4; Mon, 06 Dec 2004 16:50:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbQh0-0008Tx-O6
	for sip@megatron.ietf.org; Mon, 06 Dec 2004 16:46:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27969
	for <sip@ietf.org>; Mon, 6 Dec 2004 16:46:48 -0500 (EST)
Received: from kremlin.juniper.net ([207.17.137.120])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbQnO-0008TR-LH
	for sip@ietf.org; Mon, 06 Dec 2004 16:53:30 -0500
Received: from unknown (HELO beta.jnpr.net) (172.24.18.109)
	by kremlin.juniper.net with ESMTP; 06 Dec 2004 13:46:13 -0800
X-BrightmailFiltered: true
X-Ironport-AV: i="3.87,127,1099296000"; 
	d="scan'217,208"; a="51606040:sNHT32442084"
Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Dec 2004 13:46:12 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 6 Dec 2004 13:46:12 -0800
Message-ID: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FF5@hadron.jnpr.net>
Thread-Topic: Doubts in SIP/SDP
Thread-Index: AcTb3QEAaFwP0Sg1S9etjviP3Bhg/w==
From: "Anil Bollineni" <ABollineni@juniper.net>
To: <sip-implementors@cs.columbia.edu>, <sip@ietf.org>
X-OriginalArrivalTime: 06 Dec 2004 21:46:12.0935 (UTC)
	FILETIME=[014DD570:01C4DBDD]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Subject: [Sip] Doubts in SIP/SDP
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0809573868=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610

This is a multi-part message in MIME format.

--===============0809573868==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4DBDD.00C6F6B0"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4DBDD.00C6F6B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear All,

    I need to clear some doubts in SDP and SIP protocol specifics.=20

   1. Caller sends INVITE without the option 100Rel, callee responds
183, and 183 message is lost, can caller should receive media from
callee?. Or without 183, callee sends 200 OK, 200 OK is lost and sends
media without, it waiting ACK for 200 OK, should caller should receive
the media from callee?

  2. Assume caller sends INVITE to x.x.x.x:5060, can response to INVITE
can come from y.y.y.y:5060?

 =20

Actually these two questions are different, if there is some possibility
or the above requirements violates related RFC's, can you please let me
know. I would greatly respect the responses.

=20

Thanks in advance,

Anil

=20

=20

  =20


------_=_NextPart_001_01C4DBDD.00C6F6B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Dear All,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp; I need to clear some doubts in SDP =
and
SIP protocol specifics. </span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; 1. Caller sends INVITE without the =
option
100Rel, callee responds 183, and 183 message is lost, can caller should =
receive
media from callee?. Or without 183, callee sends 200 OK, 200 OK is lost =
and sends
media without, it waiting ACK for 200 OK, should caller should receive =
the
media from callee?</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; 2. Assume caller sends INVITE to x.x.x.x:5060, =
can
response to INVITE can come from y.y.y.y:5060?</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp; </span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Actually these two questions are different, if there =
is some
possibility or the above requirements violates related RFC&#8217;s, can =
you
please let me know. I would greatly respect the =
responses.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks in advance,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Anil</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; </span></font></p>

</div>

</body>

</html>
=00
------_=_NextPart_001_01C4DBDD.00C6F6B0--


--===============0809573868==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0809573868==--



From sip-bounces@ietf.org  Mon Dec  6 17:35:42 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02788
	for <sip-web-archive@ietf.org>; Mon, 6 Dec 2004 17:35:42 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbRYm-0001Gi-KA
	for sip-web-archive@ietf.org; Mon, 06 Dec 2004 17:42:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbRLi-0000Nd-5a; Mon, 06 Dec 2004 17:28:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbRFC-0007SV-1G
	for sip@megatron.ietf.org; Mon, 06 Dec 2004 17:22:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01621
	for <sip@ietf.org>; Mon, 6 Dec 2004 17:22:07 -0500 (EST)
Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbRLc-0000xj-IS
	for sip@ietf.org; Mon, 06 Dec 2004 17:28:49 -0500
Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93])
	by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	iB6MLbKX012289
	for <sip@ietf.org>; Mon, 6 Dec 2004 17:21:37 -0500 (EST)
Received: from sonusmail03.sonusnet.com (unverified) by sonusms1.sonusnet.com
	(Content Technologies SMTPRS 4.3.12) with ESMTP id
	<T6db5cf4d2c0a80205d3a4@sonusms1.sonusnet.com>; 
	Mon, 6 Dec 2004 17:21:37 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sip] Doubts in SIP/SDP
Date: Mon, 6 Dec 2004 17:21:36 -0500
Message-ID: <A3863F3136CBC546A40A61BA9CBA9D93F18658@sonusmail03.sonusnet.com>
Thread-Topic: Doubts in SIP/SDP
Thread-Index: AcTb3QEAaFwP0Sg1S9etjviP3Bhg/wABENzS
From: "Syed, Mohammad Rafi" <msyed@sonusnet.com>
To: "Anil Bollineni" <ABollineni@juniper.net>,
        <sip-implementors@cs.columbia.edu>, <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0360935996=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352

--===============0360935996==
content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQW5pbCwNCiANCkNhc2UgMSkNCkluIElOVklURSB3L28gb3B0aW9uIDEwMHJlbChvZmZlcikg
Y2FzZSB0aGUgY2FsbGVlIGlzIHN1cHBvc2VkIHRvIHNlbmQgYW5zd2VyKFNEUCkgaW4gMjAwIE9L
LiBpZiAyMDAgT0sgc2VudCBmcm9tIGNhbGxlZSBpcyBsb3N0IGl0cyB0aGUgY2FsbGVlJ3MgcmVz
cG9uc2liaWxpdHkgdG8gcmV0cm5hc21pdHQgMjAwIE9LLihvciBjYWxsZWUgcmV0cmFuc21pdHQg
MjAwIE9LIHVudGlsIGhlIHJlY3ZzIEFDSyBmcm9tIGNhbGxlcikuDQogDQp0aGFuayB1LA0KUmFm
aS4NCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEFuaWwgQm9sbGluZW5p
IFttYWlsdG86QUJvbGxpbmVuaUBqdW5pcGVyLm5ldF0gDQoJU2VudDogTW9uIDEyLzYvMjAwNCA0
OjQ2IFBNIA0KCVRvOiBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdTsgc2lwQGlldGYu
b3JnIA0KCUNjOiANCglTdWJqZWN0OiBbU2lwXSBEb3VidHMgaW4gU0lQL1NEUA0KCQ0KCQ0KDQoJ
RGVhciBBbGwsDQoNCgkgICAgSSBuZWVkIHRvIGNsZWFyIHNvbWUgZG91YnRzIGluIFNEUCBhbmQg
U0lQIHByb3RvY29sIHNwZWNpZmljcy4gDQoNCgkgICAxLiBDYWxsZXIgc2VuZHMgSU5WSVRFIHdp
dGhvdXQgdGhlIG9wdGlvbiAxMDBSZWwsIGNhbGxlZSByZXNwb25kcyAxODMsIGFuZCAxODMgbWVz
c2FnZSBpcyBsb3N0LCBjYW4gY2FsbGVyIHNob3VsZCByZWNlaXZlIG1lZGlhIGZyb20gY2FsbGVl
Py4gT3Igd2l0aG91dCAxODMsIGNhbGxlZSBzZW5kcyAyMDAgT0ssIDIwMCBPSyBpcyBsb3N0IGFu
ZCBzZW5kcyBtZWRpYSB3aXRob3V0LCBpdCB3YWl0aW5nIEFDSyBmb3IgMjAwIE9LLCBzaG91bGQg
Y2FsbGVyIHNob3VsZCByZWNlaXZlIHRoZSBtZWRpYSBmcm9tIGNhbGxlZT8NCg0KCSAgMi4gQXNz
dW1lIGNhbGxlciBzZW5kcyBJTlZJVEUgdG8geC54LngueDo1MDYwLCBjYW4gcmVzcG9uc2UgdG8g
SU5WSVRFIGNhbiBjb21lIGZyb20geS55LnkueTo1MDYwPw0KDQoJICANCg0KCUFjdHVhbGx5IHRo
ZXNlIHR3byBxdWVzdGlvbnMgYXJlIGRpZmZlcmVudCwgaWYgdGhlcmUgaXMgc29tZSBwb3NzaWJp
bGl0eSBvciB0aGUgYWJvdmUgcmVxdWlyZW1lbnRzIHZpb2xhdGVzIHJlbGF0ZWQgUkZD4oCZcywg
Y2FuIHlvdSBwbGVhc2UgbGV0IG1lIGtub3cuIEkgd291bGQgZ3JlYXRseSByZXNwZWN0IHRoZSBy
ZXNwb25zZXMuDQoNCgkgDQoNCglUaGFua3MgaW4gYWR2YW5jZSwNCg0KCUFuaWwNCg0KCSANCg0K
CSANCg0KCSAgIA0KDQo=


--===============0360935996==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0360935996==--


From sip-bounces@ietf.org  Mon Dec  6 17:50:16 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04007
	for <sip-web-archive@ietf.org>; Mon, 6 Dec 2004 17:50:16 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbRmr-0001dd-N2
	for sip-web-archive@ietf.org; Mon, 06 Dec 2004 17:56:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbRdk-0004HY-JX; Mon, 06 Dec 2004 17:47:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbRap-0003ak-5Y
	for sip@megatron.ietf.org; Mon, 06 Dec 2004 17:44:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03585
	for <sip@ietf.org>; Mon, 6 Dec 2004 17:44:28 -0500 (EST)
Received: from web52805.mail.yahoo.com ([206.190.39.169])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CbRhE-0001UP-ND
	for sip@ietf.org; Mon, 06 Dec 2004 17:51:10 -0500
Received: (qmail 76764 invoked by uid 60001); 6 Dec 2004 22:43:51 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	b=3wVWzyGr1P3E9Ml0cXZOrLYYGtCbZtXiZa/nTTu/dMuYCKUQaBg05I/z4HkZEUDx8x5TJQzPe3kkDF3wRd2+vDV1VZg1k0mXCUey+GBs+Am11zreSDnam6ATTV2V27UXoA+5tzEB5Uhv1wbi9bhCENAFy8+rHUcuFrbCGwQvfq8=
	; 
Message-ID: <20041206224351.76762.qmail@web52805.mail.yahoo.com>
Received: from [81.214.132.234] by web52805.mail.yahoo.com via HTTP;
	Mon, 06 Dec 2004 14:43:51 PST
Date: Mon, 6 Dec 2004 14:43:51 -0800 (PST)
From: Fatih "Eyüp" NAR <fenar@yahoo.com>
Subject: RE: [Sip] Doubts in SIP/SDP
To: "Syed, Mohammad Rafi" <msyed@sonusnet.com>,
        Anil Bollineni <ABollineni@juniper.net>,
        sip-implementors@cs.columbia.edu, sip@ietf.org
In-Reply-To: <A3863F3136CBC546A40A61BA9CBA9D93F18658@sonusmail03.sonusnet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA03585
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: quoted-printable

if u insist on to send sdp within provisional response
(180/183 etc 4 early media connection purpose ex.) and
you want to verify the reverse signalling path --> u
may use prack mechanism...

--- "Syed, Mohammad Rafi" <msyed@sonusnet.com> wrote:

> Hi Anil,
> =20
> Case 1)
> In INVITE w/o option 100rel(offer) case the callee
> is supposed to send answer(SDP) in 200 OK. if 200 OK
> sent from callee is lost its the callee's
> responsibility to retrnasmitt 200 OK.(or callee
> retransmitt 200 OK until he recvs ACK from caller).
> =20
> thank u,
> Rafi.
>=20
> 	-----Original Message-----=20
> 	From: Anil Bollineni
> [mailto:ABollineni@juniper.net]=20
> 	Sent: Mon 12/6/2004 4:46 PM=20
> 	To: sip-implementors@cs.columbia.edu; sip@ietf.org=20
> 	Cc:=20
> 	Subject: [Sip] Doubts in SIP/SDP
> =09
> =09
>=20
> 	Dear All,
>=20
> 	    I need to clear some doubts in SDP and SIP
> protocol specifics.=20
>=20
> 	   1. Caller sends INVITE without the option
> 100Rel, callee responds 183, and 183 message is
> lost, can caller should receive media from callee?.
> Or without 183, callee sends 200 OK, 200 OK is lost
> and sends media without, it waiting ACK for 200 OK,
> should caller should receive the media from callee?
>=20
> 	  2. Assume caller sends INVITE to x.x.x.x:5060,
> can response to INVITE can come from y.y.y.y:5060?
>=20
> 	 =20
>=20
> 	Actually these two questions are different, if
> there is some possibility or the above requirements
> violates related RFC=E2=80=99s, can you please let me
> know. I would greatly respect the responses.
>=20
> 	=20
>=20
> 	Thanks in advance,
>=20
> 	Anil
>=20
> 	=20
>=20
> 	=20
>=20
> 	  =20
>=20
> > _______________________________________________
> Sip mailing list=20
> https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
> Protocol
> Use sip-implementors@cs.columbia.edu for questions
> on current sip
> Use sipping@ietf.org for new developments on the
> application of sip



	=09
__________________________________=20
Do you Yahoo!?=20
Meet the all-new My Yahoo! - Try it today!=20
http://my.yahoo.com=20
=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec  6 18:01:03 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04897
	for <sip-web-archive@ietf.org>; Mon, 6 Dec 2004 18:01:03 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbRxK-0001t8-1H
	for sip-web-archive@ietf.org; Mon, 06 Dec 2004 18:07:46 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbRpn-0006qc-M5; Mon, 06 Dec 2004 17:59:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbRom-0006fZ-1E
	for sip@megatron.ietf.org; Mon, 06 Dec 2004 17:58:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04772
	for <sip@ietf.org>; Mon, 6 Dec 2004 17:58:53 -0500 (EST)
Received: from kremlin.juniper.net ([207.17.137.120])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbRvD-0001pz-P9
	for sip@ietf.org; Mon, 06 Dec 2004 18:05:36 -0500
Received: from unknown (HELO beta.jnpr.net) (172.24.18.109)
	by kremlin.juniper.net with ESMTP; 06 Dec 2004 14:58:24 -0800
X-BrightmailFiltered: true
X-Ironport-AV: i="3.87,127,1099296000"; 
	d="scan'208"; a="51612484:sNHT21014700"
Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Dec 2004 14:58:24 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1256"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Doubts in SIP/SDP
Date: Mon, 6 Dec 2004 14:58:23 -0800
Message-ID: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FF6@hadron.jnpr.net>
Thread-Topic: [Sip] Doubts in SIP/SDP
Thread-Index: AcTb5RAoMqC+vz9bRRmFm1GMZ8IsNwAABK6g
From: "Anil Bollineni" <ABollineni@juniper.net>
To: "Fatih \"Ey|p\" NAR" <fenar@yahoo.com>,
        "Syed, Mohammad Rafi" <msyed@sonusnet.com>,
        <sip-implementors@cs.columbia.edu>, <sip@ietf.org>
X-OriginalArrivalTime: 06 Dec 2004 22:58:24.0481 (UTC)
	FILETIME=[171B4D10:01C4DBE7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Content-Transfer-Encoding: quoted-printable
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Content-Transfer-Encoding: quoted-printable

Hi,
   Thanks for the response. Actually I may confuse you. Specifically, if =
the callee sends the media after 183, and 183 is lost, will the caller =
should accept the media, because it don't know codec should the media =
expect or caller should decode whatever is coming, by finding the codecs =
in the list it offers. Sorry I don't know that it is the basic =
requirement, but in RFC can I find the statements that tell the media =
starts after the SDP negotiation is completed.
My options are
    INVITE------------->		OR INVITE ------------>
	      <--------183 (lost)		      <-------->183(lost)
     drop<----------------media	    accept<-----------(media)


Thanks,
Anil

-----Original Message-----
From: Fatih "Ey|p" NAR [mailto:fenar@yahoo.com]=20
Sent: Monday, December 06, 2004 2:44 PM
To: Syed, Mohammad Rafi; Anil Bollineni; =
sip-implementors@cs.columbia.edu; sip@ietf.org
Subject: RE: [Sip] Doubts in SIP/SDP

if u insist on to send sdp within provisional response
(180/183 etc 4 early media connection purpose ex.) and
you want to verify the reverse signalling path --> u
may use prack mechanism...

--- "Syed, Mohammad Rafi" <msyed@sonusnet.com> wrote:

> Hi Anil,
> =20
> Case 1)
> In INVITE w/o option 100rel(offer) case the callee
> is supposed to send answer(SDP) in 200 OK. if 200 OK
> sent from callee is lost its the callee's
> responsibility to retrnasmitt 200 OK.(or callee
> retransmitt 200 OK until he recvs ACK from caller).
> =20
> thank u,
> Rafi.
>=20
> 	-----Original Message-----=20
> 	From: Anil Bollineni
> [mailto:ABollineni@juniper.net]=20
> 	Sent: Mon 12/6/2004 4:46 PM=20
> 	To: sip-implementors@cs.columbia.edu; sip@ietf.org=20
> 	Cc:=20
> 	Subject: [Sip] Doubts in SIP/SDP
> =09
> =09
>=20
> 	Dear All,
>=20
> 	    I need to clear some doubts in SDP and SIP
> protocol specifics.=20
>=20
> 	   1. Caller sends INVITE without the option
> 100Rel, callee responds 183, and 183 message is
> lost, can caller should receive media from callee?.
> Or without 183, callee sends 200 OK, 200 OK is lost
> and sends media without, it waiting ACK for 200 OK,
> should caller should receive the media from callee?
>=20
> 	  2. Assume caller sends INVITE to x.x.x.x:5060,
> can response to INVITE can come from y.y.y.y:5060?
>=20
> 	 =20
>=20
> 	Actually these two questions are different, if
> there is some possibility or the above requirements
> violates related RFC=E2=80=99s, can you please let me
> know. I would greatly respect the responses.
>=20
> 	=20
>=20
> 	Thanks in advance,
>=20
> 	Anil
>=20
> 	=20
>=20
> 	=20
>=20
> 	  =20
>=20
> > _______________________________________________
> Sip mailing list=20
> https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
> Protocol
> Use sip-implementors@cs.columbia.edu for questions
> on current sip
> Use sipping@ietf.org for new developments on the
> application of sip



	=09
__________________________________=20
Do you Yahoo!?=20
Meet the all-new My Yahoo! - Try it today!=20
http://my.yahoo.com=20
=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec  6 18:22:08 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07496
	for <sip-web-archive@ietf.org>; Mon, 6 Dec 2004 18:22:08 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbSHS-0002Ju-T4
	for sip-web-archive@ietf.org; Mon, 06 Dec 2004 18:28:51 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbS9x-0001Fq-Lu; Mon, 06 Dec 2004 18:20:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbS0Z-0004jd-GR
	for sip@megatron.ietf.org; Mon, 06 Dec 2004 18:11:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06397
	for <sip@ietf.org>; Mon, 6 Dec 2004 18:11:04 -0500 (EST)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbS70-00028m-90
	for sip@ietf.org; Mon, 06 Dec 2004 18:17:47 -0500
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 06 Dec 2004 18:10:37 -0500
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB6NAWqR021336; 
	Mon, 6 Dec 2004 18:10:33 -0500 (EST)
Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR)
	with ESMTP id ANM78274; Mon, 6 Dec 2004 18:10:32 -0500 (EST)
Message-ID: <41B4E6E8.1090805@cisco.com>
Date: Mon, 06 Dec 2004 18:10:32 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anil Bollineni <ABollineni@juniper.net>
Subject: Re: [Sip-implementors] RE: [Sip] Doubts in SIP/SDP
References: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FF6@hadron.jnpr.net>
Content-Type: text/plain; charset=windows-1256; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA06397
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Content-Transfer-Encoding: quoted-printable

Anil,

At the time you send an offer you should be prepared to receive media on=20
the offered port, using *any* of the codecs in the offer. Whether you=20
receive the 183 with answer is irrelevant to that. The 183 with answer=20
in this case potentially allows you to send early media, and possibly=20
narrows down the list of codecs used for media you receive. The loss of=20
the 183 prevents you from sending early but has no other important=20
effect, since the same SDP will be repeated in the 200.

	Paul

Anil Bollineni wrote:
> Hi,
>    Thanks for the response. Actually I may confuse you. Specifically, i=
f the callee sends the media after 183, and 183 is lost, will the caller =
should accept the media, because it don't know codec should the media exp=
ect or caller should decode whatever is coming, by finding the codecs in =
the list it offers. Sorry I don't know that it is the basic requirement, =
but in RFC can I find the statements that tell the media starts after the=
 SDP negotiation is completed.
> My options are
>     INVITE------------->		OR INVITE ------------>
> 	      <--------183 (lost)		      <-------->183(lost)
>      drop<----------------media	    accept<-----------(media)
>=20
>=20
> Thanks,
> Anil
>=20
> -----Original Message-----
> From: Fatih "Ey|p" NAR [mailto:fenar@yahoo.com]=20
> Sent: Monday, December 06, 2004 2:44 PM
> To: Syed, Mohammad Rafi; Anil Bollineni; sip-implementors@cs.columbia.e=
du; sip@ietf.org
> Subject: RE: [Sip] Doubts in SIP/SDP
>=20
> if u insist on to send sdp within provisional response
> (180/183 etc 4 early media connection purpose ex.) and
> you want to verify the reverse signalling path --> u
> may use prack mechanism...
>=20
> --- "Syed, Mohammad Rafi" <msyed@sonusnet.com> wrote:
>=20
>=20
>>Hi Anil,
>>=20
>>Case 1)
>>In INVITE w/o option 100rel(offer) case the callee
>>is supposed to send answer(SDP) in 200 OK. if 200 OK
>>sent from callee is lost its the callee's
>>responsibility to retrnasmitt 200 OK.(or callee
>>retransmitt 200 OK until he recvs ACK from caller).
>>=20
>>thank u,
>>Rafi.
>>
>>	-----Original Message-----=20
>>	From: Anil Bollineni
>>[mailto:ABollineni@juniper.net]=20
>>	Sent: Mon 12/6/2004 4:46 PM=20
>>	To: sip-implementors@cs.columbia.edu; sip@ietf.org=20
>>	Cc:=20
>>	Subject: [Sip] Doubts in SIP/SDP
>>=09
>>=09
>>
>>	Dear All,
>>
>>	    I need to clear some doubts in SDP and SIP
>>protocol specifics.=20
>>
>>	   1. Caller sends INVITE without the option
>>100Rel, callee responds 183, and 183 message is
>>lost, can caller should receive media from callee?.
>>Or without 183, callee sends 200 OK, 200 OK is lost
>>and sends media without, it waiting ACK for 200 OK,
>>should caller should receive the media from callee?
>>
>>	  2. Assume caller sends INVITE to x.x.x.x:5060,
>>can response to INVITE can come from y.y.y.y:5060?
>>
>>	 =20
>>
>>	Actually these two questions are different, if
>>there is some possibility or the above requirements
>>violates related RFC=E2=80=99s, can you please let me
>>know. I would greatly respect the responses.
>>
>>	=20
>>
>>	Thanks in advance,
>>
>>	Anil
>>
>>	=20
>>
>>	=20
>>
>>	  =20
>>
>>
>>>_______________________________________________
>>
>>Sip mailing list=20
>>https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP
>>Protocol
>>Use sip-implementors@cs.columbia.edu for questions
>>on current sip
>>Use sipping@ietf.org for new developments on the
>>application of sip
>=20
>=20
>=20
>=20
> 	=09
> __________________________________=20
> Do you Yahoo!?=20
> Meet the all-new My Yahoo! - Try it today!=20
> http://my.yahoo.com=20
> =20
>=20
>=20
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec  6 18:56:38 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09357
	for <sip-web-archive@ietf.org>; Mon, 6 Dec 2004 18:56:38 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbSp7-0002uY-TD
	for sip-web-archive@ietf.org; Mon, 06 Dec 2004 19:03:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbSef-0001yP-0B; Mon, 06 Dec 2004 18:52:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbScP-0001N9-Kk
	for sip@megatron.ietf.org; Mon, 06 Dec 2004 18:50:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09041
	for <sip@ietf.org>; Mon, 6 Dec 2004 18:50:10 -0500 (EST)
Received: from borg.juniper.net ([207.17.137.119])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbSir-0002nD-Mz
	for sip@ietf.org; Mon, 06 Dec 2004 18:56:54 -0500
Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126)
	by borg.juniper.net with ESMTP; 06 Dec 2004 15:49:41 -0800
X-BrightmailFiltered: true
X-Ironport-AV: i="3.87,127,1099296000"; 
	d="scan'208"; a="44056125:sNHT25774548"
Received: from hadron.jnpr.net ([172.24.15.25]) by alpha.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Dec 2004 15:49:41 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1256"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip-implementors] RE: [Sip] Doubts in SIP/SDP
Date: Mon, 6 Dec 2004 15:49:40 -0800
Message-ID: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FF7@hadron.jnpr.net>
Thread-Topic: [Sip-implementors] RE: [Sip] Doubts in SIP/SDP
Thread-Index: AcTb6MwB70ATUc2+SN2JLjQTQo0SeQABH6PQ
From: "Anil Bollineni" <ABollineni@juniper.net>
To: "Paul Kyzivat" <pkyzivat@cisco.com>
X-OriginalArrivalTime: 06 Dec 2004 23:49:41.0824 (UTC)
	FILETIME=[41589400:01C4DBEE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Content-Transfer-Encoding: quoted-printable

Hi Paul,
  Thanks for the response. For example, if in normal INVITE/200/ACK =
scenarios, as soon as callee answers the phone (there by UAS starts the =
media), UAS sends 200 OK, and assume it is lost, will UAC should play =
the media received from callee?
 OR
 When the callee answers the phone, should not UAS send the media until =
it receives ACK for 200 OK and starts the media. Which one is more good?
I think the first one is valid, and in that sense the callee is =
responsible for the billing that he speaks.

Thanks
Anil

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20
Sent: Monday, December 06, 2004 3:11 PM
To: Anil Bollineni
Cc: Fatih "Ey|p" NAR; Syed, Mohammad Rafi; =
sip-implementors@cs.columbia.edu; sip@ietf.org
Subject: Re: [Sip-implementors] RE: [Sip] Doubts in SIP/SDP

Anil,

At the time you send an offer you should be prepared to receive media on =

the offered port, using *any* of the codecs in the offer. Whether you=20
receive the 183 with answer is irrelevant to that. The 183 with answer=20
in this case potentially allows you to send early media, and possibly=20
narrows down the list of codecs used for media you receive. The loss of=20
the 183 prevents you from sending early but has no other important=20
effect, since the same SDP will be repeated in the 200.

	Paul

Anil Bollineni wrote:
> Hi,
>    Thanks for the response. Actually I may confuse you. Specifically, =
if the callee sends the media after 183, and 183 is lost, will the =
caller should accept the media, because it don't know codec should the =
media expect or caller should decode whatever is coming, by finding the =
codecs in the list it offers. Sorry I don't know that it is the basic =
requirement, but in RFC can I find the statements that tell the media =
starts after the SDP negotiation is completed.
> My options are
>     INVITE------------->		OR INVITE ------------>
> 	      <--------183 (lost)		      <-------->183(lost)
>      drop<----------------media	    accept<-----------(media)
>=20
>=20
> Thanks,
> Anil
>=20
> -----Original Message-----
> From: Fatih "Ey|p" NAR [mailto:fenar@yahoo.com]=20
> Sent: Monday, December 06, 2004 2:44 PM
> To: Syed, Mohammad Rafi; Anil Bollineni; =
sip-implementors@cs.columbia.edu; sip@ietf.org
> Subject: RE: [Sip] Doubts in SIP/SDP
>=20
> if u insist on to send sdp within provisional response
> (180/183 etc 4 early media connection purpose ex.) and
> you want to verify the reverse signalling path --> u
> may use prack mechanism...
>=20
> --- "Syed, Mohammad Rafi" <msyed@sonusnet.com> wrote:
>=20
>=20
>>Hi Anil,
>>=20
>>Case 1)
>>In INVITE w/o option 100rel(offer) case the callee
>>is supposed to send answer(SDP) in 200 OK. if 200 OK
>>sent from callee is lost its the callee's
>>responsibility to retrnasmitt 200 OK.(or callee
>>retransmitt 200 OK until he recvs ACK from caller).
>>=20
>>thank u,
>>Rafi.
>>
>>	-----Original Message-----=20
>>	From: Anil Bollineni
>>[mailto:ABollineni@juniper.net]=20
>>	Sent: Mon 12/6/2004 4:46 PM=20
>>	To: sip-implementors@cs.columbia.edu; sip@ietf.org=20
>>	Cc:=20
>>	Subject: [Sip] Doubts in SIP/SDP
>>=09
>>=09
>>
>>	Dear All,
>>
>>	    I need to clear some doubts in SDP and SIP
>>protocol specifics.=20
>>
>>	   1. Caller sends INVITE without the option
>>100Rel, callee responds 183, and 183 message is
>>lost, can caller should receive media from callee?.
>>Or without 183, callee sends 200 OK, 200 OK is lost
>>and sends media without, it waiting ACK for 200 OK,
>>should caller should receive the media from callee?
>>
>>	  2. Assume caller sends INVITE to x.x.x.x:5060,
>>can response to INVITE can come from y.y.y.y:5060?
>>
>>	 =20
>>
>>	Actually these two questions are different, if
>>there is some possibility or the above requirements
>>violates related RFC=E2=80=99s, can you please let me
>>know. I would greatly respect the responses.
>>
>>	=20
>>
>>	Thanks in advance,
>>
>>	Anil
>>
>>	=20
>>
>>	=20
>>
>>	  =20
>>
>>
>>>_______________________________________________
>>
>>Sip mailing list=20
>>https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP
>>Protocol
>>Use sip-implementors@cs.columbia.edu for questions
>>on current sip
>>Use sipping@ietf.org for new developments on the
>>application of sip
>=20
>=20
>=20
>=20
> 	=09
> __________________________________=20
> Do you Yahoo!?=20
> Meet the all-new My Yahoo! - Try it today!=20
> http://my.yahoo.com=20
> =20
>=20
>=20
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec  7 00:43:45 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04908
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 00:43:45 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbYF4-0001jr-Ow
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 00:50:32 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbY6g-0003zj-Cc; Tue, 07 Dec 2004 00:41:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbY2n-00036j-1U
	for sip@megatron.ietf.org; Tue, 07 Dec 2004 00:37:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04639
	for <sip@ietf.org>; Tue, 7 Dec 2004 00:37:46 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbY9H-0001eS-Dq for sip@ietf.org; Tue, 07 Dec 2004 00:44:32 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 06 Dec 2004 22:45:40 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB75bDD9019522;
	Mon, 6 Dec 2004 21:37:14 -0800 (PST)
Received: from [192.168.1.100] (che-vpn-cluster-2-132.cisco.com
	[10.86.242.132]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR)
	with ESMTP id AGD90873; Mon, 6 Dec 2004 21:37:12 -0800 (PST)
Message-ID: <41B54187.3050801@cisco.com>
Date: Tue, 07 Dec 2004 00:37:11 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: privacy without b2bua, was: Re: third alternative (was RE: [Sip]
	RE: Identity after reinvite)
References: <BDD664F4.1CD92%fluffy@cisco.com>
In-Reply-To: <BDD664F4.1CD92%fluffy@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Paul H Kyzivat <pkyzivat@cisco.com>,
        Dave Oran <oran@cisco.com>, Jon Peterson <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit



Cullen Jennings wrote:

> I agree with the direction this is going but I think the anonymization
> services needs to be a bit more complex than a simple TURN server. A simple
> TURN server would make it too easy to do statistical timing analysis of the
> incoming and outgoing traffic and form the connections about who is taking
> to who.

I'm not sure I follow how this attack works; can you elaborate?

Of course this is always an issue of all anonymization servers - a
> service with only one user that is known is not all that anonymous.

How is the user known evne in this case? Recognizing the voice or 
something you mean?


  Anyways,
> I think we could easily work up to something based along the lines of the
> approach described below that is not  too complex to describe and is
> significantly stronger than a simple relay.

Another related approach would be to have the client use the transcoding 
framework 
(http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-3pcc-02.txt), 
though I think the turn approach might have better security properties - 
need to think about it though.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec  7 01:05:38 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06266
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 01:05:38 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbYaE-0002Ak-4M
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 01:12:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbYS6-0007Nc-0a; Tue, 07 Dec 2004 01:03:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbYOp-0006vw-Hr
	for sip@megatron.ietf.org; Tue, 07 Dec 2004 01:00:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05948
	for <sip@ietf.org>; Tue, 7 Dec 2004 01:00:34 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbYVJ-000240-NR for sip@ietf.org; Tue, 07 Dec 2004 01:07:19 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 06 Dec 2004 23:08:26 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB75xsD9027513;
	Mon, 6 Dec 2004 21:59:54 -0800 (PST)
Received: from [192.168.1.100] (che-vpn-cluster-2-132.cisco.com
	[10.86.242.132]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR)
	with ESMTP id AGD91451; Mon, 6 Dec 2004 21:59:55 -0800 (PST)
Message-ID: <41B546DB.1070603@cisco.com>
Date: Tue, 07 Dec 2004 00:59:55 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] PING/PONG
References: <CD9775120D600F43B9C50329395E9DB64F321F@ivor.citel.com>
	<13719E43-3D96-11D9-93B0-000D93326732@nostrum.com>
	<41A43E4D.8020102@cisco.com>
	<59BC20AE-3E26-11D9-93B0-000D93326732@nostrum.com>
	<41B135A5.1040208@cisco.com>
	<53A35690-4796-11D9-8F23-000D93326732@nostrum.com>
In-Reply-To: <53A35690-4796-11D9-8F23-000D93326732@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, Christian Stredicke <Christian.Stredicke@snom.de>,
        Steve Langstaff <steve.langstaff@citel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit



Robert Sparks wrote:

> I hope we're talking past each other at this point.
> 
> You seem to be proposing that I would _never_ open a connection with 
> anything but
> one proxy, even if I had network visibility to something else and the 
> knowledge that
> I wanted to talk to it.

No; I'm saying that opening one up as a result of a record-route is not 
going to work.

> 
> I'm saying that if I want to have a dialog with something that I can 
> reach (but it can't
> open a connection to me), that I want to open a connection to it and for 
> the duration
> of that dialog, keep the connection alive. My original point is that I 
> want to use the
> same mechanism we define for keeping a connection to a proxy alive.

I think its fine to open a connection to something else, then send it a 
sip invite to create a sip dialog. What I think is a problem is opening 
one up to an element whose address I learn from a record-route after 
getting the 200 OK to my invite.

> 
> I think maybe you're only seeing the "tried to place a call and it ended 
> up on some
> random voicemail server" use case in your response below. Look at it from a
> retrieving voicemail point of view. Then consider other services (like a 
> presence server)
> I might like to use, perhaps from a third party provider.

Those are ok, since it looks exactly like the normal persistent proxy 
connection case.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec  7 08:03:57 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25063
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 08:03:57 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cbf77-0002Y5-Uf
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 08:10:46 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cbevm-0005kS-Eq; Tue, 07 Dec 2004 07:59:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbepg-0004Mh-05
	for sip@megatron.ietf.org; Tue, 07 Dec 2004 07:52:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23882
	for <sip@ietf.org>; Tue, 7 Dec 2004 07:52:42 -0500 (EST)
Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbewE-000257-Tz
	for sip@ietf.org; Tue, 07 Dec 2004 07:59:31 -0500
Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2657.72)
	id <YNNTPACT>; Tue, 7 Dec 2004 12:52:03 -0000
Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E53309@baker.datcon.co.uk>
From: "Paul D.Smith" <Paul.D.Smith@dataconnection.com>
To: "'rohan@ekabal.com'" <rohan@ekabal.com>
Date: Tue, 7 Dec 2004 12:52:05 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4DC5B.8E2A0670"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221
Cc: SIP WG <sip@ietf.org>, "Paul D.Smith" <Paul.D.Smith@dataconnection.com>
Subject: [Sip] RE: [Sipping] I-D
	ACTION:draft-ietf-sipping-dialog-package-05.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C4DC5B.8E2A0670
Content-Type: text/plain;
	charset="iso-8859-1"

Rohan,

As per my earlier post to the group, I have to disagree with your
assertion that a 408 or 481 failure of _any_ mid-dialog request
terminates the dialog (section 3.7.1 of this draft).

  "Once in the confirmed state, the call is active.  It can transition
   to the terminated state if the UAC sends a BYE or receives a BYE
   (corresponding to the "local-bye" and "remote-bye" events as
   appropriate), if a mid-dialog request generates a 481 or 408 response
   (corresponding to the "error" event), or a mid-dialog request
   generates no response (corresponding to the "timeout" event)."

RFC3261 is quite clear in distinguishing between BYE requests and other
requests.  The failure of a non-BYE request does not cause a dialog to
terminate although it should be taken as a prompt to the UA to end the
dialog
by sending a BYE.  To put it another way, non-BYE requests are not dialog
terminating, regardless of the status code of any resulting response.

If you believe this is not the case, can you please explain the meaning of
the following sections of RFC3261.

12.3 Termination of a Dialog

   Independent of the method, if a request outside of a dialog generates
   a non-2xx final response, any early dialogs created through
   provisional responses to that request are terminated.  The mechanism
   for terminating confirmed dialogs is method specific.  In this
   specification, the BYE method terminates a session and the dialog
   associated with it.  See Section 15 for details.

12.2.1.2 Processing the Responses

   ...

   If the response for a request within a dialog is a 481
   (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
   SHOULD terminate the dialog.  A UAC SHOULD also terminate a dialog if
   no response at all is received for the request (the client
   transaction would inform the TU about the timeout.)

      For INVITE initiated dialogs, terminating the dialog consists of
      sending a BYE.

I believe this is a serious issue because it potentially means that there
would be two concepts of the state of a dialog, one RFC3261 compliant and
a second, compliant to this draft.  I therefore believe this should be
resolved quickly and look forward to readong your response.

Regards,
Paul D Smith
Network Protocols Group 
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: paul.d.smith@dataconnection.com 
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com



-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: 23 November 2004 21:11
To: SIP Public Folder (E-mail)
Subject: [Sipping] I-D ACTION:draft-ietf-sipping-dialog-package-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Session Initiation Proposal Investigation
Working Group of the IETF.

	Title		: An INVITE Inititiated Dialog Event Package for the
                          Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg, et al.
	Filename	: draft-ietf-sipping-dialog-package-05.txt
	Pages		: 39
	Date		: 2004-11-23
	
This document defines a dialog event package for the SIP Events
architecture, along with a data format used in notifications for this
package. The dialog package allows users to subscribe to another
user, an receive notifications about the changes in state of INVITE
initiated dialogs that the user is involved in.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-dialog-package-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-dialog-package-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


------_=_NextPart_000_01C4DC5B.8E2A0670
Content-Type: message/rfc822

To: 
Subject: 
Date: Tue, 7 Dec 2004 12:52:03 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C4DC5B.8E2A0670"


------_=_NextPart_002_01C4DC5B.8E2A0670
Content-Type: text/plain



------_=_NextPart_002_01C4DC5B.8E2A0670
Content-Type: application/octet-stream;
	name="ATT79302.txt"
Content-Disposition: attachment;
	filename="ATT79302.txt"

Content-type: message/external-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2004-11-23143811.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sipping-dialog-package-05.txt

------_=_NextPart_002_01C4DC5B.8E2A0670
Content-Type: message/external-body; site="internet-drafts";
	dir="draft-ietf-sipping-dialog-package-05.txt";
	mode="ftp.ietf.org"; access-type="anon-ftp"



------_=_NextPart_002_01C4DC5B.8E2A0670--

------_=_NextPart_000_01C4DC5B.8E2A0670
Content-Type: text/plain;
	name="ATT79303.txt"
Content-Disposition: attachment;
	filename="ATT79303.txt"

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
------_=_NextPart_000_01C4DC5B.8E2A0670
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
------_=_NextPart_000_01C4DC5B.8E2A0670--



From sip-bounces@ietf.org  Tue Dec  7 08:07:39 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25514
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 08:07:39 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbfAg-0002fn-HG
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 08:14:27 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cbevo-0005kh-0V; Tue, 07 Dec 2004 07:59:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbeqL-0004S3-Uc; Tue, 07 Dec 2004 07:53:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23913;
	Tue, 7 Dec 2004 07:53:24 -0500 (EST)
Received: from smtp.dataconnection.com ([192.91.191.4] helo=smtp.datcon.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cbewu-00025k-Sf; Tue, 07 Dec 2004 08:00:13 -0500
Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2657.72)
	id <YNNTPACZ>; Tue, 7 Dec 2004 12:52:48 -0000
Message-ID: <53F74F5A7B94D511841C00B0D0AB16F803E5330A@baker.datcon.co.uk>
From: "Paul D.Smith" <Paul.D.Smith@dataconnection.com>
To: SIPPING WG <sipping@ietf.org>
Date: Tue, 7 Dec 2004 12:52:51 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4DC5B.A9202F90"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b
Cc: SIP WG <sip@ietf.org>
Subject: [Sip] FW: [Sipping] I-D
	ACTION:draft-ietf-sipping-dialog-package-05.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a492040269d440726bfd84680622cee7

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C4DC5B.A9202F90
Content-Type: text/plain;
	charset="iso-8859-1"

Apologies - this e-mail should have gone to the SIPPING WG!

Paul DS.

-----Original Message-----
From: Paul D.Smith 
Sent: 07 December 2004 12:52
To: SIP Public Folder (E-mail)
Subject: RE: [Sipping] I-D
ACTION:draft-ietf-sipping-dialog-package-05.txt


Rohan,

As per my earlier post to the group, I have to disagree with your
assertion that a 408 or 481 failure of _any_ mid-dialog request
terminates the dialog (section 3.7.1 of this draft).

  "Once in the confirmed state, the call is active.  It can transition
   to the terminated state if the UAC sends a BYE or receives a BYE
   (corresponding to the "local-bye" and "remote-bye" events as
   appropriate), if a mid-dialog request generates a 481 or 408 response
   (corresponding to the "error" event), or a mid-dialog request
   generates no response (corresponding to the "timeout" event)."

RFC3261 is quite clear in distinguishing between BYE requests and other
requests.  The failure of a non-BYE request does not cause a dialog to
terminate although it should be taken as a prompt to the UA to end the
dialog
by sending a BYE.  To put it another way, non-BYE requests are not dialog
terminating, regardless of the status code of any resulting response.

If you believe this is not the case, can you please explain the meaning of
the following sections of RFC3261.

12.3 Termination of a Dialog

   Independent of the method, if a request outside of a dialog generates
   a non-2xx final response, any early dialogs created through
   provisional responses to that request are terminated.  The mechanism
   for terminating confirmed dialogs is method specific.  In this
   specification, the BYE method terminates a session and the dialog
   associated with it.  See Section 15 for details.

12.2.1.2 Processing the Responses

   ...

   If the response for a request within a dialog is a 481
   (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
   SHOULD terminate the dialog.  A UAC SHOULD also terminate a dialog if
   no response at all is received for the request (the client
   transaction would inform the TU about the timeout.)

      For INVITE initiated dialogs, terminating the dialog consists of
      sending a BYE.

I believe this is a serious issue because it potentially means that there
would be two concepts of the state of a dialog, one RFC3261 compliant and
a second, compliant to this draft.  I therefore believe this should be
resolved quickly and look forward to readong your response.

Regards,
Paul D Smith
Network Protocols Group 
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: paul.d.smith@dataconnection.com 
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com



-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: 23 November 2004 21:11
To: SIP Public Folder (E-mail)
Subject: [Sipping] I-D ACTION:draft-ietf-sipping-dialog-package-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Session Initiation Proposal Investigation
Working Group of the IETF.

	Title		: An INVITE Inititiated Dialog Event Package for the
                          Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg, et al.
	Filename	: draft-ietf-sipping-dialog-package-05.txt
	Pages		: 39
	Date		: 2004-11-23
	
This document defines a dialog event package for the SIP Events
architecture, along with a data format used in notifications for this
package. The dialog package allows users to subscribe to another
user, an receive notifications about the changes in state of INVITE
initiated dialogs that the user is involved in.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-dialog-package-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-dialog-package-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


------_=_NextPart_000_01C4DC5B.A9202F90
Content-Type: message/rfc822

To: 
Subject: 
Date: Tue, 7 Dec 2004 12:52:48 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C4DC5B.A9202F90"


------_=_NextPart_002_01C4DC5B.A9202F90
Content-Type: text/plain



------_=_NextPart_002_01C4DC5B.A9202F90
Content-Type: application/octet-stream;
	name="ATT79302.txt"
Content-Disposition: attachment;
	filename="ATT79302.txt"

Content-type: message/external-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2004-11-23143811.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sipping-dialog-package-05.txt

------_=_NextPart_002_01C4DC5B.A9202F90
Content-Type: message/external-body; site="internet-drafts";
	dir="draft-ietf-sipping-dialog-package-05.txt";
	mode="ftp.ietf.org"; access-type="anon-ftp"



------_=_NextPart_002_01C4DC5B.A9202F90--

------_=_NextPart_000_01C4DC5B.A9202F90
Content-Type: text/plain;
	name="ATT79303.txt"
Content-Disposition: attachment;
	filename="ATT79303.txt"

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
------_=_NextPart_000_01C4DC5B.A9202F90
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
------_=_NextPart_000_01C4DC5B.A9202F90--



From sip-bounces@ietf.org  Tue Dec  7 11:06:23 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17807
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 11:06:23 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cbhxi-0007UK-O0
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 11:13:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbhnK-0005hb-Mu; Tue, 07 Dec 2004 11:02:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbhWZ-0001V4-8r
	for sip@megatron.ietf.org; Tue, 07 Dec 2004 10:45:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15330
	for <sip@ietf.org>; Tue, 7 Dec 2004 10:45:09 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbhd7-0006q6-Kr
	for sip@ietf.org; Tue, 07 Dec 2004 10:52:00 -0500
Received: from [192.168.0.100] (c-24-1-68-89.client.comcast.net [24.1.68.89])
	(authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iB7FipNr073883
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 7 Dec 2004 09:44:56 -0600 (CST)
	(envelope-from rjsparks@nostrum.com)
In-Reply-To: <41B546DB.1070603@cisco.com>
References: <CD9775120D600F43B9C50329395E9DB64F321F@ivor.citel.com>
	<13719E43-3D96-11D9-93B0-000D93326732@nostrum.com>
	<41A43E4D.8020102@cisco.com>
	<59BC20AE-3E26-11D9-93B0-000D93326732@nostrum.com>
	<41B135A5.1040208@cisco.com>
	<53A35690-4796-11D9-8F23-000D93326732@nostrum.com>
	<41B546DB.1070603@cisco.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <EC9C3468-4866-11D9-8F23-000D93326732@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [Sip] PING/PONG
Date: Tue, 7 Dec 2004 09:44:47 -0600
To: Jonathan Rosenberg <jdrosen@cisco.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, Christian Stredicke <Christian.Stredicke@snom.de>,
        Steve Langstaff <steve.langstaff@citel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit


On Dec 6, 2004, at 11:59 PM, Jonathan Rosenberg wrote:

>
>
> Robert Sparks wrote:
>
>> I hope we're talking past each other at this point.
>> You seem to be proposing that I would _never_ open a connection with 
>> anything but
>> one proxy, even if I had network visibility to something else and the 
>> knowledge that
>> I wanted to talk to it.
>
> No; I'm saying that opening one up as a result of a record-route is 
> not going to work.

Then we have been talking past each other. I wasn't suggesting you 
would.

>
>> I'm saying that if I want to have a dialog with something that I can 
>> reach (but it can't
>> open a connection to me), that I want to open a connection to it and 
>> for the duration
>> of that dialog, keep the connection alive. My original point is that 
>> I want to use the
>> same mechanism we define for keeping a connection to a proxy alive.
>
> I think its fine to open a connection to something else, then send it 
> a sip invite to create a sip dialog. What I think is a problem is 
> opening one up to an element whose address I learn from a record-route 
> after getting the 200 OK to my invite.
>
>> I think maybe you're only seeing the "tried to place a call and it 
>> ended up on some
>> random voicemail server" use case in your response below. Look at it 
>> from a
>> retrieving voicemail point of view. Then consider other services 
>> (like a presence server)
>> I might like to use, perhaps from a third party provider.
>
> Those are ok, since it looks exactly like the normal persistent proxy 
> connection case.
>
> -Jonathan R.
>
>
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> jdrosen@cisco.com                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec  7 14:04:24 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06747
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 14:04:24 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cbkjz-0003MF-Mz
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 14:11:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbkUE-0007lC-Q6; Tue, 07 Dec 2004 13:54:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbkMe-0006Ck-W1
	for sip@megatron.ietf.org; Tue, 07 Dec 2004 13:47:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05346
	for <sip@ietf.org>; Tue, 7 Dec 2004 13:47:07 -0500 (EST)
Received: from figas.ekabal.com ([204.61.215.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbkTG-0002wm-0i
	for sip@ietf.org; Tue, 07 Dec 2004 13:53:59 -0500
Received: from [172.16.16.78] (da001d4094.stl-mo.osd.concentric.net
	[66.236.111.254] (may be forged)) (authenticated)
	by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id iB7IkBX30878;
	Tue, 7 Dec 2004 10:46:16 -0800
In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F803E53309@baker.datcon.co.uk>
References: <53F74F5A7B94D511841C00B0D0AB16F803E53309@baker.datcon.co.uk>
Mime-Version: 1.0 (Apple Message framework v619)
Message-Id: <38E34FA2-4880-11D9-87CF-000D93C60450@ekabal.com>
From: Rohan Mahy <rohan@ekabal.com>
Date: Tue, 7 Dec 2004 10:45:53 -0800
To: "Paul D.Smith" <Paul.D.Smith@dataconnection.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ce9c9805f9fd7f2a8e6eb8268c6b0fc
Cc: SIP WG <sip@ietf.org>, Rohan Mahy <rohan@ekabal.com>
Subject: [Sip] Re: [Sipping] I-D
	ACTION:draft-ietf-sipping-dialog-package-05.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0862094889=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 87e958510a39f65fbeb5ae8b5e360e3b


--===============0862094889==
Content-Type: multipart/alternative; boundary=Apple-Mail-2--416098368


--Apple-Mail-2--416098368
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

Paul,

In SIP each dialog has a pair of peers.  They each maintain local  
dialog state and they maintain their idea of the remote dialog state.   
While SIP goes to great lengths to encourage that the my view of my  
peer's state and my peer's view of his or her state are the consistent  
most of the time. However, in the absence of globally synchronized  
clocks, it is impossible to make this state consistent *all* of the  
time. Necessarily, there are periods of time (which are typically short  
in ordinary operational environments) during which each peer has a  
different view of the network state.  For example I am in a stable call  
with Alice.  Her dialog state is active and my dialog state is active.   
Now I send a BYE.  My dialog state is terminated, but her dialog state  
is still active until she receives my BYE.  This is a feature.

Now we move to the problem at hand.  I send a mid-dialog request and  
receive a 481 response.  My peer clearly believes that the dialog is  
terminated. I will immediately send a BYE to alert any proxies in the  
path that the call is over.  The question is whether I now represent my  
state using the dialog package as active or terminated.

I can mark my state as terminated and immediately send a BYE and any  
notifications about this change more or less simultaneously.  As I  
describe below, I don't see any contradiction with RFC 3261, and this  
seems a reasonable and practical way to implement the event package.

Alternatively, I could leave the state as active after I receive the  
481 until I send the BYE. There are several problems with this:
- there is nothing I could possibly do, nor any message I could receive  
that would cause me to still consider the dialog truly active.
- representing the state as active is disingenuous.  The other end  
already considers the dialog over, and I am about to tell any proxys in  
the path that I consider the dialog terminated as well.  If a new  
SUBSCRIBE arrives before I send the BYE, I would tell the subscriber  
about a call that is effectively gone.
- If I transition to terminated by sending a BYE, then the reason would  
be "local-bye" instead of "error" or "timeout", which represents a loss  
of useful information.
- since I should send the BYE immediately, when the transition occurs  
is rather academic.  Even if I wait until I send the BYE to change the  
state, a NOTIFY advertising this change could still arrive at a  
subscriber before the BYE arrives at the first proxy (the first BYE  
could be retransmitted).

Additional comments on the relevant sections in 3261 below...


On Dec 7, 2004, at 4:52, Paul D.Smith wrote:
> Rohan,
>
> As per my earlier post to the group, I have to disagree with your
> assertion that a 408 or 481 failure of _any_ mid-dialog request
> terminates the dialog (section 3.7.1 of this draft).
>
>   "Once in the confirmed state, the call is active.  It can transition
>    to the terminated state if the UAC sends a BYE or receives a BYE
>    (corresponding to the "local-bye" and "remote-bye" events as
>    appropriate), if a mid-dialog request generates a 481 or 408  
> response
>    (corresponding to the "error" event), or a mid-dialog request
>    generates no response (corresponding to the "timeout" event)."
>
> RFC3261 is quite clear in distinguishing between BYE requests and other
> requests.  The failure of a non-BYE request does not cause a dialog to
> terminate although it should be taken as a prompt to the UA to end the
> dialog
> by sending a BYE.  To put it another way, non-BYE requests are not  
> dialog
> terminating, regardless of the status code of any resulting response.
>
> If you believe this is not the case, can you please explain the  
> meaning of
> the following sections of RFC3261.
>
> 12.3 Termination of a Dialog
>
>    Independent of the method, if a request outside of a dialog  
> generates
>    a non-2xx final response, any early dialogs created through
>    provisional responses to that request are terminated.  The mechanism
>    for terminating confirmed dialogs is method specific.  In this
>    specification, the BYE method terminates a session and the dialog
>    associated with it.  See Section 15 for details.

this statement does not prevent other methods of terminating a session  
(notably CANCEL, or receiving a 6xx class response to the initial  
INVITE).

> 12.2.1.2 Processing the Responses
>    ...
>    If the response for a request within a dialog is a 481
>    (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the  
> UAC
>    SHOULD terminate the dialog.  A UAC SHOULD also terminate a dialog  
> if
>    no response at all is received for the request (the client
>    transaction would inform the TU about the timeout.)

this statement clearly says that a mid-dialog 481 or 408 terminates the  
dialog.

Why this is a SHOULD instead of a MUST is something I do not know, and  
I suspect this is a bug in the spec.  I personally cannot think of what  
an implementor might do instead.  I believe the SHOULD might actually  
apply to the fact that you SHOULD send a BYE, but if there are no  
intervening proxies, there is no reason to do so.

>       For INVITE initiated dialogs, terminating the dialog consists of
>       sending a BYE.

this is an informative statement (all indented statements in 3261 are  
informative).

3261 should probably be more explicit as to why you should send a BYE  
when you think the dialog is already terminated (so proxies can be  
informed of this if they care).  However there is already a bug filed  
on the spec about clarifying the difference between terminating a usage  
of a dialog and the dialog itself. Indeed, per Robert Sparks's  
discussion about dialog usages, if I have a session started with  
INVITE, and then add a subscription with a REFER, do I need to also  
terminate the subscription usage of the dialog by sending a BYE and a  
NOTIFY Subscription-State: terminated?

> I believe this is a serious issue because it potentially means that  
> there
> would be two concepts of the state of a dialog, one RFC3261 compliant  
> and
> a second, compliant to this draft.

I do not believe that there are two concepts of dialog state.  I think  
you are having confusion around an informative statement in RFC3261  
which is unclear.

thanks,
-rohan

> I therefore believe this should be
> resolved quickly and look forward to reading your response.
>
> Regards,
> Paul D Smith
> Network Protocols Group
> Data Connection Ltd (DCL)
> Tel: +44 20 8366 1177  Email: paul.d.smith@dataconnection.com
> Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com
>
>
>
> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: 23 November 2004 21:11
> To: SIP Public Folder (E-mail)
> Subject: [Sipping] I-D ACTION:draft-ietf-sipping-dialog-package-05.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Session Initiation Proposal  
> Investigation
> Working Group of the IETF.
>
> 	Title		: An INVITE Inititiated Dialog Event Package for the
>                           Session Initiation Protocol (SIP)
> 	Author(s)	: J. Rosenberg, et al.
> 	Filename	: draft-ietf-sipping-dialog-package-05.txt
> 	Pages		: 39
> 	Date		: 2004-11-23
> 	
> This document defines a dialog event package for the SIP Events
> architecture, along with a data format used in notifications for this
> package. The dialog package allows users to subscribe to another
> user, an receive notifications about the changes in state of INVITE
> initiated dialogs that the user is involved in.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package 
> -05.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of  
> the
> message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the  
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-sipping-dialog-package-05.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-sipping-dialog-package-05.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> Date: December 7, 2004 4:52:03 PST
> To: Subject:
>
>
>
> <ATT79302.txt>
>
> <ATT79303.txt>
--Apple-Mail-2--416098368
Content-Type: text/enriched;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

Paul,


In SIP each dialog has a pair of peers.  They each maintain local
dialog state and they maintain their idea of the remote dialog state. 
While SIP goes to great lengths to encourage that the my view of my
peer's state and my peer's view of his or her state are the consistent
most of the time. However, in the absence of globally synchronized
clocks, it is impossible to make this state consistent *all* of the
time. Necessarily, there are periods of time (which are typically
short in ordinary operational environments) during which each peer has
a different view of the network state.  For example I am in a stable
call with Alice.  Her dialog state is active and my dialog state is
active.  Now I send a BYE.  My dialog state is terminated, but her
dialog state is still active until she receives my BYE.  This is a
feature.


Now we move to the problem at hand.  I send a mid-dialog request and
receive a 481 response.  My peer clearly believes that the dialog is
terminated. I will immediately send a BYE to alert any proxies in the
path that the call is over.  The question is whether I now represent
my state using the dialog package as active or terminated.


I can mark my state as terminated and immediately send a BYE and any
notifications about this change more or less simultaneously.  As I
describe below, I don't see any contradiction with RFC 3261, and this
seems a reasonable and practical way to implement the event package.


Alternatively, I could leave the state as active after I receive the
481 until I send the BYE. There are several problems with this:

- there is nothing I could possibly do, nor any message I could
receive that would cause me to still consider the dialog truly active.

- representing the state as active is disingenuous.  The other end
already considers the dialog over, and I am about to tell any proxys
in the path that I consider the dialog terminated as well.  If a new
SUBSCRIBE arrives before I send the BYE, I would tell the subscriber
about a call that is effectively gone.

- If I transition to terminated by sending a BYE, then the reason
would be "local-bye" instead of "error" or "timeout", which represents
a loss of useful information.

- since I should send the BYE immediately, when the transition occurs
is rather academic.  Even if I wait until I send the BYE to change the
state, a NOTIFY advertising this change could still arrive at a
subscriber before the BYE arrives at the first proxy (the first BYE
could be retransmitted).


Additional comments on the relevant sections in 3261 below...



On Dec 7, 2004, at 4:52, Paul D.Smith wrote:

<excerpt>Rohan,


As per my earlier post to the group, I have to disagree with your

assertion that a 408 or 481 failure of _any_ mid-dialog request

terminates the dialog (section 3.7.1 of this draft).


  "Once in the confirmed state, the call is active.  It can transition

   to the terminated state if the UAC sends a BYE or receives a BYE

   (corresponding to the "local-bye" and "remote-bye" events as

   appropriate), if a mid-dialog request generates a 481 or 408
response

   (corresponding to the "error" event), or a mid-dialog request

   generates no response (corresponding to the "timeout" event)."


RFC3261 is quite clear in distinguishing between BYE requests and other

requests.  The failure of a non-BYE request does not cause a dialog to

terminate although it should be taken as a prompt to the UA to end the

dialog

by sending a BYE.  To put it another way, non-BYE requests are not
dialog

terminating, regardless of the status code of any resulting response.


If you believe this is not the case, can you please explain the
meaning of

the following sections of RFC3261.


12.3 Termination of a Dialog


   Independent of the method, if a request outside of a dialog
generates

   a non-2xx final response, any early dialogs created through

   provisional responses to that request are terminated.  The mechanism

   for terminating confirmed dialogs is method specific.  In this

   specification, the BYE method terminates a session and the dialog

   associated with it.  See Section 15 for details.

</excerpt>

this statement does not prevent other methods of terminating a session
(notably CANCEL, or receiving a 6xx class response to the initial
INVITE).


<excerpt>12.2.1.2 Processing the Responses

   ...

   If the response for a request within a dialog is a 481

   (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the
UAC

   SHOULD terminate the dialog.  A UAC SHOULD also terminate a dialog
if

   no response at all is received for the request (the client

   transaction would inform the TU about the timeout.)

</excerpt>

this statement clearly says that a mid-dialog 481 or 408 terminates
the dialog. 


Why this is a SHOULD instead of a MUST is something I do not know, and
I suspect this is a bug in the spec.  I personally cannot think of
what an implementor might do instead.  I believe the SHOULD might
actually apply to the fact that you SHOULD send a BYE, but if there
are no intervening proxies, there is no reason to do so.


<excerpt>      For INVITE initiated dialogs, terminating the dialog
consists of

      sending a BYE.

</excerpt>

this is an informative statement (all indented statements in 3261 are
informative).  


3261 should probably be more explicit as to why you should send a BYE
when you think the dialog is already terminated (so proxies can be
informed of this if they care).  However there is already a bug filed
on the spec about clarifying the difference between terminating a
usage of a dialog and the dialog itself. Indeed, per Robert Sparks's
discussion about dialog usages, if I have a session started with
INVITE, and then add a subscription with a REFER, do I need to also
terminate the subscription usage of the dialog by sending a BYE and a
NOTIFY Subscription-State: terminated?  


<excerpt>I believe this is a serious issue because it potentially
means that there

would be two concepts of the state of a dialog, one RFC3261 compliant
and

a second, compliant to this draft. 

</excerpt>

I do not believe that there are two concepts of dialog state.  I think
you are having confusion around an informative statement in RFC3261
which is unclear.


thanks,

-rohan


<excerpt>I therefore believe this should be

resolved quickly and look forward to reading your response.


Regards,

Paul D Smith

Network Protocols Group 

Data Connection Ltd (DCL)

Tel: +44 20 8366 1177  Email: paul.d.smith@dataconnection.com 

Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com




-----Original Message-----

From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]

Sent: 23 November 2004 21:11

To: SIP Public Folder (E-mail)

Subject: [Sipping] I-D ACTION:draft-ietf-sipping-dialog-package-05.txt



A New Internet-Draft is available from the on-line Internet-Drafts

directories.

This draft is a work item of the Session Initiation Proposal
Investigation

Working Group of the IETF.


	Title		: An INVITE Inititiated Dialog Event Package for the

                          Session Initiation Protocol (SIP)

	Author(s)	: J. Rosenberg, et al.

	Filename	: draft-ietf-sipping-dialog-package-05.txt

	Pages		: 39

	Date		: 2004-11-23

	

This document defines a dialog event package for the SIP Events

architecture, along with a data format used in notifications for this

package. The dialog package allows users to subscribe to another

user, an receive notifications about the changes in state of INVITE

initiated dialogs that the user is involved in.


A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt


To remove yourself from the I-D Announcement list, send a message to 

i-d-announce-request@ietf.org with the word unsubscribe in the body of
the

message.  

You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 

to change your subscription settings.



Internet-Drafts are also available by anonymous FTP. Login with the
username

"anonymous" and a password of your e-mail address. After logging in,

type "cd internet-drafts" and then

	"get draft-ietf-sipping-dialog-package-05.txt".


A list of Internet-Drafts directories can be found in

http://www.ietf.org/shadow.html 

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



Internet-Drafts can also be obtained by e-mail.


Send a message to:

	mailserv@ietf.org.

In the body type:

	"FILE /internet-drafts/draft-ietf-sipping-dialog-package-05.txt".

	

NOTE:	The mail server at ietf.org can return the document in

	MIME-encoded form by using the "mpack" utility.  To use this

	feature, insert the command "ENCODING mime" before the "FILE"

	command.  To decode the response(s), you will need "munpack" or

	a MIME-compliant mail reader.  Different MIME-compliant mail readers

	exhibit different behavior, especially when dealing with

	"multipart" MIME messages (i.e. documents which have been split

	up into multiple messages), so check your local documentation on

	how to manipulate these messages.

		

		

Below is the data which will enable a MIME compliant mail reader

implementation to automatically retrieve the ASCII version of the

Internet-Draft.


<bold><color><param>0000,0000,0000</param>

Date: </color></bold>December 7, 2004 4:52:03 PST

<bold><color><param>0000,0000,0000</param>To: Subject: </color>

</bold>



<<ATT79302.txt>


<<ATT79303.txt></excerpt>
--Apple-Mail-2--416098368--



--===============0862094889==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0862094889==--




From sip-bounces@ietf.org  Tue Dec  7 14:39:23 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11221
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 14:39:23 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CblHr-0004Kd-3h
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 14:46:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cbl7H-0007TD-DA; Tue, 07 Dec 2004 14:35:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbky3-0005aZ-F6
	for sip@megatron.ietf.org; Tue, 07 Dec 2004 14:25:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09329
	for <sip@ietf.org>; Tue, 7 Dec 2004 14:25:46 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cbl4f-0003vp-8D for sip@ietf.org; Tue, 07 Dec 2004 14:32:38 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-3.cisco.com with ESMTP; 07 Dec 2004 12:33:45 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB7JP5IT008137;
	Tue, 7 Dec 2004 11:25:06 -0800 (PST)
Received: from [10.0.1.3] (sjc-vpn5-561.cisco.com [10.21.90.49])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUO12456;
	Tue, 7 Dec 2004 11:25:11 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Tue, 07 Dec 2004 11:25:16 -0800
Subject: Re: privacy without b2bua, was: Re: third alternative (was RE:
	[Sip] RE: Identity after reinvite)
From: Cullen Jennings <fluffy@cisco.com>
To: Jonathan Rosenberg <jdrosen@cisco.com>
Message-ID: <BDDB439C.1D4FB%fluffy@cisco.com>
In-Reply-To: <41B54187.3050801@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Paul H Kyzivat <pkyzivat@cisco.com>,
        Dave Oran <oran@cisco.com>, Jon Peterson <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit

On 12/6/04 9:37 PM, "Jonathan Rosenberg" <jdrosen@cisco.com> wrote:

> 
> 
> Cullen Jennings wrote:
> 
>> I agree with the direction this is going but I think the anonymization
>> services needs to be a bit more complex than a simple TURN server. A simple
>> TURN server would make it too easy to do statistical timing analysis of the
>> incoming and outgoing traffic and form the connections about who is taking
>> to who.
> 
> I'm not sure I follow how this attack works; can you elaborate?
> 

Alice sends a packet to the the anonymizer, and the next packet out of the
anonymizer goes to Bob. If you can watch the traffic in and out of the
anonymizer, it becomes clear that Alice is talking to Bob. One solution is
to have enough traffic that you can delay packets slightly and send packets
to many places within the time delay.




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec  7 15:24:47 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16270
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 15:24:47 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cblzm-0005Kj-KT
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 15:31:40 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cblnh-0002kS-5n; Tue, 07 Dec 2004 15:19:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbllB-0000be-0Y
	for sip@megatron.ietf.org; Tue, 07 Dec 2004 15:16:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15279
	for <sip@ietf.org>; Tue, 7 Dec 2004 15:16:31 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cblrj-0005AW-P0
	for sip@ietf.org; Tue, 07 Dec 2004 15:23:24 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-4.cisco.com with ESMTP; 07 Dec 2004 12:11:13 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB7KB8D9012133;
	Tue, 7 Dec 2004 12:11:08 -0800 (PST)
Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iB7KAGFP023887;
	Tue, 7 Dec 2004 12:10:16 -0800
Subject: Re: privacy without b2bua, was: Re: third alternative (was RE:
	[Sip] RE: Identity after reinvite)
From: Michael Thomas <mat@cisco.com>
To: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <BDDB439C.1D4FB%fluffy@cisco.com>
References: <BDDB439C.1D4FB%fluffy@cisco.com>
Organization: Cisco Systems
Message-Id: <1102450269.17444.5.camel@thomasm-lnx.cisco.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Tue, 07 Dec 2004 12:11:09 -0800
IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1102450216.596856"; x:"432200"; a:"rsa-sha1"; b:"nofws:1367";
	e:"Iw==";
	n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw"
	"eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU"
	"tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"BBfyx4rLrL/MaGzB89wpjIgN+RJRdKCJgk5ot10sCr+hLFEYdHofizwRcM+CP"
	"diUihIBazwb4AW238l8s9JByTRIg7ADDCRAL3jSeb71ujsbK9Q65H+CHgqvRv"
	"D9tdlozt0TIOJoS3gJIlU3hLiEEqRuLbvYSM7KR7lfp5oRj0c=";
	c:"Subject: Re: privacy without b2bua,
	was: Re: third alternative (was RE"
	":=0A	[Sip] RE: Identity after reinvite)";
	c:"From: Michael Thomas <mat@cisco.com>";
	c:"Date: Tue, 07 Dec 2004 12:11:09 -0800"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: "sip@ietf.org" <sip@ietf.org>, Paul H Kyzivat <pkyzivat@cisco.com>,
        Dave Oran <oran@cisco.com>, Jon Peterson <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2077629687=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0


--===============2077629687==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-jOYWw0aPh3iOEhHrFQkn"


--=-jOYWw0aPh3iOEhHrFQkn
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2004-12-07 at 11:25, Cullen Jennings wrote:
> Alice sends a packet to the the anonymizer, and the next packet out of th=
e
> anonymizer goes to Bob. If you can watch the traffic in and out of the
> anonymizer, it becomes clear that Alice is talking to Bob. One solution i=
s
> to have enough traffic that you can delay packets slightly and send packe=
ts
> to many places within the time delay.

This strikes me as a losing proposition: if I can do
traffic analysis at the anonymizer, you are probably not
likely to remain very anonymous, or at least anonymous
enough for government work. In order for this to really
work, you'd need a routing equivalent of P-boxes (and=20
S-boxes?) for a suitably large value of P. Or something.

		Mike

--=-jOYWw0aPh3iOEhHrFQkn
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iQCVAwUAQbYOXLMsDAj/Eq++AQLffQP+N0hID3LtpviONnsKysl7y99RzKOFqCqp
WPuYScN4DBAra6C7ox+VLiEEVGqNUhnfDTom4H2DYbExWgIcBMvExB9+af5gfXgb
b8063PgdPBvIXRFzt73COTSuObAA3R2Z7qSNmBKcrOANQXrDSpolsmqrr83IUejo
XVJUyiF7wbA=
=ffgB
-----END PGP SIGNATURE-----

--=-jOYWw0aPh3iOEhHrFQkn--


--===============2077629687==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============2077629687==--



From sip-bounces@ietf.org  Tue Dec  7 16:49:01 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01574
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 16:49:01 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbnJM-0000zP-6w
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 16:55:56 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbmUv-0007lI-4W; Tue, 07 Dec 2004 16:03:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbmSO-00068q-SS; Tue, 07 Dec 2004 16:01:12 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20320;
	Tue, 7 Dec 2004 16:01:10 -0500 (EST)
Message-Id: <200412072101.QAA20320@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Date: Tue, 07 Dec 2004 16:01:10 -0500
Cc: sip@ietf.org
Subject: [Sip] I-D ACTION:draft-ietf-sip-history-info-05.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.4 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: An Extension to the Session Initiation Protocol 
			  for Request History Information
	Author(s)	: M. Barnes
	Filename	: draft-ietf-sip-history-info-05.txt
	Pages		: 48
	Date		: 2004-12-7
	
This draft defines a standard mechanism for capturing the history 
   information associated with a SIP request.  This capability enables 
   many enhanced services by providing the information as to how and why 
   a call arrives at a specific application or user.  This draft defines 
   a new optional SIP header, History-Info, for capturing the history 
   information in requests. A new option tag, Histinfo, to be included 
   in the Supported header, is defined to allow UAs to indicate whether 
   the History-Info should be returned in responses to a request which 
   has captured the history information. A new priv-value, history, is 
   added to the Privacy header to allow for privacy handling of the 
   History-Info header.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-history-info-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-history-info-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2004-12-7154051.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-history-info-05.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-sip-history-info-05.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2004-12-7154051.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--NextPart--





From sip-bounces@ietf.org  Tue Dec  7 17:29:54 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07317
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 17:29:54 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cbnwu-0002hE-GV
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 17:36:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cbnkd-0005BD-D5; Tue, 07 Dec 2004 17:24:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbnSb-0007ax-PF
	for sip@megatron.ietf.org; Tue, 07 Dec 2004 17:05:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04785
	for <sip@ietf.org>; Tue, 7 Dec 2004 17:05:27 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbnZF-00020H-SH
	for sip@ietf.org; Tue, 07 Dec 2004 17:12:22 -0500
Received: from [63.110.3.236] ([12.5.186.26]) (authenticated bits=0)
	by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iB7M5uEk020800
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 7 Dec 2004 16:05:59 -0600
In-Reply-To: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FF6@hadron.jnpr.net>
References: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FF6@hadron.jnpr.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0EF8A402-489C-11D9-A339-000D93594350@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Doubts in SIP/SDP
Date: Tue, 7 Dec 2004 16:05:08 -0600
To: "Anil Bollineni" <ABollineni@juniper.net>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit


On Dec 6, 2004, at 4:58 PM, Anil Bollineni wrote:

> Hi,
>    Thanks for the response. Actually I may confuse you. Specifically, 
> if the callee sends the media after 183, and 183 is lost, will the 
> caller should accept the media, because it don't know codec should the 
> media expect or caller should decode whatever is coming, by finding 
> the codecs in the list it offers. Sorry I don't know that it is the 
> basic requirement, but in RFC can I find the statements that tell the 
> media starts after the SDP negotiation is completed.
>

I believe the rule is "the caller MUST be ready to receive any media 
described in the SDP of an INVITE immediately after sending that 
INVITE." This is how we get all those neat early-media use-cases.

Note that this use case frequently occurs when placing a call from SIP 
through a PSTN gateway (with ISDN) that terminates on a PSTN IVR, like 
that used by American Airlines. The "answer" SDP arrives in a 200OK 
that is sent by the gateway after the PSTN circuit moves into connected 
state. However, the phone circuit is not in the "connected" state for 
the first round of engagement with the IVR. The gateway in my office 
will only tolerate this for about 32 seconds before it gives up on the 
INVITE, so I have to navigate the first level of the IVR quickly.

--
Dean 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec  7 17:35:53 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07934
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 17:35:53 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cbo2h-0002rg-9z
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 17:42:48 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cbnko-0005HC-1l; Tue, 07 Dec 2004 17:24:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbnVC-0000oS-LW
	for sip@megatron.ietf.org; Tue, 07 Dec 2004 17:08:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05053
	for <sip@ietf.org>; Tue, 7 Dec 2004 17:08:08 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbnbp-00025G-JY
	for sip@ietf.org; Tue, 07 Dec 2004 17:15:03 -0500
Received: from [63.110.3.236] ([12.5.186.26]) (authenticated bits=0)
	by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iB7M8l11020821
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 7 Dec 2004 16:08:52 -0600
In-Reply-To: <BDDB439C.1D4FB%fluffy@cisco.com>
References: <BDDB439C.1D4FB%fluffy@cisco.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <74D6903E-489C-11D9-A339-000D93594350@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: privacy without b2bua,
	was: Re: third alternative (was RE: [Sip] RE: Identity after reinvite)
Date: Tue, 7 Dec 2004 16:07:59 -0600
To: Cullen Jennings <fluffy@cisco.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Paul H Kyzivat <pkyzivat@cisco.com>,
        Dave Oran <oran@cisco.com>, Jon Peterson <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit


On Dec 7, 2004, at 1:25 PM, Cullen Jennings wrote:

> Alice sends a packet to the the anonymizer, and the next packet out of 
> the
> anonymizer goes to Bob. If you can watch the traffic in and out of the
> anonymizer, it becomes clear that Alice is talking to Bob. One 
> solution is
> to have enough traffic that you can delay packets slightly and send 
> packets
> to many places within the time delay.
>

Methinks a B2BUA would be subject to the same sort of analysis attack.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec  7 18:06:18 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11298
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 18:06:18 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CboW8-0003gF-Pb
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 18:13:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CboHY-0007rF-7D; Tue, 07 Dec 2004 17:58:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbo3y-0003nF-8j
	for sip@megatron.ietf.org; Tue, 07 Dec 2004 17:44:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08820
	for <sip@ietf.org>; Tue, 7 Dec 2004 17:44:03 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CboAb-00036e-QO for sip@ietf.org; Tue, 07 Dec 2004 17:50:59 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 07 Dec 2004 14:46:05 -0800
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB7MhUIT016578;
	Tue, 7 Dec 2004 14:43:31 -0800 (PST)
Received: from [192.168.1.100] (che-vpn-cluster-2-132.cisco.com
	[10.86.242.132]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR)
	with ESMTP id AGE41273; Tue, 7 Dec 2004 14:43:29 -0800 (PST)
Message-ID: <41B6320D.2000904@cisco.com>
Date: Tue, 07 Dec 2004 17:43:25 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Subject: Re: privacy without b2bua, was: Re: third alternative (was RE: [Sip]
	RE: Identity after reinvite)
References: <BDDB439C.1D4FB%fluffy@cisco.com>
	<74D6903E-489C-11D9-A339-000D93594350@softarmor.com>
In-Reply-To: <74D6903E-489C-11D9-A339-000D93594350@softarmor.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, "sip@ietf.org" <sip@ietf.org>,
        Paul H Kyzivat <pkyzivat@cisco.com>, Dave Oran <oran@cisco.com>,
        Jon Peterson <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit

I agree with Dean here.

I think that the attack the anonymizer is trying to prevent is one where 
the "attacker" is just a participant in the call; that is, we are not 
worried about cases where they are eavesdropping on other calls or 
attacking the anonymizers, etc.

-Jonathan R.

Dean Willis wrote:
> 
> On Dec 7, 2004, at 1:25 PM, Cullen Jennings wrote:
> 
>> Alice sends a packet to the the anonymizer, and the next packet out of 
>> the
>> anonymizer goes to Bob. If you can watch the traffic in and out of the
>> anonymizer, it becomes clear that Alice is talking to Bob. One 
>> solution is
>> to have enough traffic that you can delay packets slightly and send 
>> packets
>> to many places within the time delay.
>>
> 
> Methinks a B2BUA would be subject to the same sort of analysis attack.
> 
> -- 
> Dean
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec  7 19:17:53 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19352
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 19:17:52 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbpdR-0005Ot-FE
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 19:24:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CbpUf-0007MQ-VP; Tue, 07 Dec 2004 19:15:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CbpQJ-000606-Is
	for sip@megatron.ietf.org; Tue, 07 Dec 2004 19:11:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18491
	for <sip@ietf.org>; Tue, 7 Dec 2004 19:11:12 -0500 (EST)
Received: from borg.juniper.net ([207.17.137.119])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbpWx-0005DO-HU
	for sip@ietf.org; Tue, 07 Dec 2004 19:18:09 -0500
Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126)
	by borg.juniper.net with ESMTP; 07 Dec 2004 16:10:41 -0800
X-BrightmailFiltered: true
X-Ironport-AV: i="3.87,129,1099296000"; 
	d="scan'208"; a="44186988:sNHT22683394"
Received: from hadron.jnpr.net ([172.24.15.25]) by alpha.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Dec 2004 16:10:41 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Doubts in SIP/SDP
Date: Tue, 7 Dec 2004 16:10:40 -0800
Message-ID: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FFF@hadron.jnpr.net>
Thread-Topic: [Sip] Doubts in SIP/SDP
Thread-Index: AcTcqN509g7qzdAKTGKdJhvl99hmkAAD+wzg
From: "Anil Bollineni" <ABollineni@juniper.net>
To: "Dean Willis" <dean.willis@softarmor.com>
X-OriginalArrivalTime: 08 Dec 2004 00:10:41.0835 (UTC)
	FILETIME=[5AC8BFB0:01C4DCBA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: quoted-printable

Hi,
  Thanks for the response. I have a basic question, considering 3 views.

1. Suppose terminating endpoint does not support 183, and sends the
early media for IVR, should  UAC, play the media treated as if early
media.=20

2. Any case the terminating endpoint must support 183 and send the media
after it sends. The 100rel is optional, in this case the sequence of 183
and early media is not guaranteed. Should UAC prepare media irrespective
of call progress message?
3. In case of 100Rel calling UA requires the option 100rel, should
terminating endpoint MUST send always after PRACK is received?

Specifically, if we want deploy a firewall between originating and
terminating endpoints, should we allow early media after INVITE without
183 is being seen?

Thanks,
Anil

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]=20
Sent: Tuesday, December 07, 2004 2:05 PM
To: Anil Bollineni
Cc: Syed, Mohammad Rafi; Fatih "Ey|p" NAR;
sip-implementors@cs.columbia.edu; sip@ietf.org
Subject: Re: [Sip] Doubts in SIP/SDP


On Dec 6, 2004, at 4:58 PM, Anil Bollineni wrote:

> Hi,
>    Thanks for the response. Actually I may confuse you. Specifically,=20
> if the callee sends the media after 183, and 183 is lost, will the=20
> caller should accept the media, because it don't know codec should the

> media expect or caller should decode whatever is coming, by finding=20
> the codecs in the list it offers. Sorry I don't know that it is the=20
> basic requirement, but in RFC can I find the statements that tell the=20
> media starts after the SDP negotiation is completed.
>

I believe the rule is "the caller MUST be ready to receive any media=20
described in the SDP of an INVITE immediately after sending that=20
INVITE." This is how we get all those neat early-media use-cases.

Note that this use case frequently occurs when placing a call from SIP=20
through a PSTN gateway (with ISDN) that terminates on a PSTN IVR, like=20
that used by American Airlines. The "answer" SDP arrives in a 200OK=20
that is sent by the gateway after the PSTN circuit moves into connected=20
state. However, the phone circuit is not in the "connected" state for=20
the first round of engagement with the IVR. The gateway in my office=20
will only tolerate this for about 32 seconds before it gives up on the=20
INVITE, so I have to navigate the first level of the IVR quickly.

--
Dean=20


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec  7 19:58:14 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23545
	for <sip-web-archive@ietf.org>; Tue, 7 Dec 2004 19:58:14 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CbqGU-0006JJ-1k
	for sip-web-archive@ietf.org; Tue, 07 Dec 2004 20:05:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cbq3j-0000Wc-Sk; Tue, 07 Dec 2004 19:51:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbq1U-000894-LI
	for sip@megatron.ietf.org; Tue, 07 Dec 2004 19:49:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22770
	for <sip@ietf.org>; Tue, 7 Dec 2004 19:49:37 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cbq88-00066A-8z for sip@ietf.org; Tue, 07 Dec 2004 19:56:34 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 07 Dec 2004 16:51:39 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB80mkIT004771;
	Tue, 7 Dec 2004 16:49:02 -0800 (PST)
Received: from [10.0.1.3] (sjc-vpn5-775.cisco.com [10.21.91.7])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUO46877;
	Tue, 7 Dec 2004 16:48:47 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Tue, 07 Dec 2004 16:48:54 -0800
Subject: Re: privacy without b2bua, was: Re: third alternative (was RE:
	[Sip] RE: Identity after reinvite)
From: Cullen Jennings <fluffy@cisco.com>
To: Jonathan Rosenberg <jdrosen@cisco.com>,
        Dean Willis <dean.willis@softarmor.com>
Message-ID: <BDDB8F76.1D6D4%fluffy@cisco.com>
In-Reply-To: <41B6320D.2000904@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Paul H Kyzivat <pkyzivat@cisco.com>,
        Dave Oran <oran@cisco.com>, Jon Peterson <jon.peterson@neustar.biz>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit


Fair enough - there are many levels one can go to to try and be anonymous -
depends on what your attack model is.

On 12/7/04 2:43 PM, "Jonathan Rosenberg" <jdrosen@cisco.com> wrote:

> I agree with Dean here.
> 
> I think that the attack the anonymizer is trying to prevent is one where
> the "attacker" is just a participant in the call; that is, we are not
> worried about cases where they are eavesdropping on other calls or
> attacking the anonymizers, etc.
> 
> -Jonathan R.
> 
> Dean Willis wrote:
>> 
>> On Dec 7, 2004, at 1:25 PM, Cullen Jennings wrote:
>> 
>>> Alice sends a packet to the the anonymizer, and the next packet out of
>>> the
>>> anonymizer goes to Bob. If you can watch the traffic in and out of the
>>> anonymizer, it becomes clear that Alice is talking to Bob. One
>>> solution is
>>> to have enough traffic that you can delay packets slightly and send
>>> packets
>>> to many places within the time delay.
>>> 
>> 
>> Methinks a B2BUA would be subject to the same sort of analysis attack.
>> 
>> -- 
>> Dean
>> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec  8 09:04:27 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26173
	for <sip-web-archive@ietf.org>; Wed, 8 Dec 2004 09:04:27 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cc2XR-00066T-Ah
	for sip-web-archive@ietf.org; Wed, 08 Dec 2004 09:11:29 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cc2HR-0004p9-34; Wed, 08 Dec 2004 08:54:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc2DZ-0003ph-6W
	for sip@megatron.ietf.org; Wed, 08 Dec 2004 08:50:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25248
	for <sip@ietf.org>; Wed, 8 Dec 2004 08:50:55 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cc2KL-0005m4-Dl for sip@ietf.org; Wed, 08 Dec 2004 08:57:57 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-3.cisco.com with ESMTP; 08 Dec 2004 06:55:44 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB8DoJm4002823;
	Wed, 8 Dec 2004 05:50:19 -0800 (PST)
Received: from cisco.com (che-vpn-cluster-1-7.cisco.com [10.86.240.7])
	by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANN88959;
	Wed, 8 Dec 2004 08:50:17 -0500 (EST)
Message-ID: <41B70699.6050608@cisco.com>
Date: Wed, 08 Dec 2004 08:50:17 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anil Bollineni <ABollineni@juniper.net>
Subject: Re: [Sip-implementors] RE: [Sip] Doubts in SIP/SDP
References: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FFF@hadron.jnpr.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu,
        Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Content-Transfer-Encoding: 7bit



Anil Bollineni wrote:
> Hi,
>   Thanks for the response. I have a basic question, considering 3 views.
> 
> 1. Suppose terminating endpoint does not support 183, and sends the
> early media for IVR, should  UAC, play the media treated as if early
> media. 

Dean was pretty clear - you should be prepared to receive media as soon 
as you send the offer, even before you receive *any* signaling in 
response. What you do with it after it is received is your problem, but 
in general you SHOULD render it.

> 2. Any case the terminating endpoint must support 183 and send the media
> after it sends. The 100rel is optional, in this case the sequence of 183
> and early media is not guaranteed. Should UAC prepare media irrespective
> of call progress message?

Nobody is *obligated* to *send* a 183. So you can't put a MUST on that. 
Nor is there any requirement to *send* media. You send media if and when 
you have media to send, once you have a place to send it.

> 3. In case of 100Rel calling UA requires the option 100rel, should
> terminating endpoint MUST send always after PRACK is received?
> 
> Specifically, if we want deploy a firewall between originating and
> terminating endpoints, should we allow early media after INVITE without
> 183 is being seen?

Firewalls are evil, though perhaps necessary. In general one hopes they 
do as little harm as possible. Your firewall SHOULD allow early media 
after the invite, before any response. You may decide to be more heavy 
handed, but if so be prepared to have some unhappy users.

	Paul

> Thanks,
> Anil
> 
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com] 
> Sent: Tuesday, December 07, 2004 2:05 PM
> To: Anil Bollineni
> Cc: Syed, Mohammad Rafi; Fatih "Ey|p" NAR;
> sip-implementors@cs.columbia.edu; sip@ietf.org
> Subject: Re: [Sip] Doubts in SIP/SDP
> 
> 
> On Dec 6, 2004, at 4:58 PM, Anil Bollineni wrote:
> 
> 
>>Hi,
>>   Thanks for the response. Actually I may confuse you. Specifically, 
>>if the callee sends the media after 183, and 183 is lost, will the 
>>caller should accept the media, because it don't know codec should the
> 
> 
>>media expect or caller should decode whatever is coming, by finding 
>>the codecs in the list it offers. Sorry I don't know that it is the 
>>basic requirement, but in RFC can I find the statements that tell the 
>>media starts after the SDP negotiation is completed.
>>
> 
> 
> I believe the rule is "the caller MUST be ready to receive any media 
> described in the SDP of an INVITE immediately after sending that 
> INVITE." This is how we get all those neat early-media use-cases.
> 
> Note that this use case frequently occurs when placing a call from SIP 
> through a PSTN gateway (with ISDN) that terminates on a PSTN IVR, like 
> that used by American Airlines. The "answer" SDP arrives in a 200OK 
> that is sent by the gateway after the PSTN circuit moves into connected 
> state. However, the phone circuit is not in the "connected" state for 
> the first round of engagement with the IVR. The gateway in my office 
> will only tolerate this for about 32 seconds before it gives up on the 
> INVITE, so I have to navigate the first level of the IVR quickly.
> 
> --
> Dean 
> 
> 
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec  8 23:32:28 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01338
	for <sip-web-archive@ietf.org>; Wed, 8 Dec 2004 23:32:28 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcG5b-0003It-3Q
	for sip-web-archive@ietf.org; Wed, 08 Dec 2004 23:39:40 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcFuv-0007Ii-7e; Wed, 08 Dec 2004 23:28:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcFr7-0005gn-1W; Wed, 08 Dec 2004 23:24:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00786;
	Wed, 8 Dec 2004 23:24:38 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcFy0-0003A4-87; Wed, 08 Dec 2004 23:31:49 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 08 Dec 2004 20:26:53 -0800
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com
	[171.71.163.28])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB94Nxm4010826;
	Wed, 8 Dec 2004 20:24:00 -0800 (PST)
Received: from [192.168.1.100] (che-vpn-cluster-2-180.cisco.com
	[10.86.242.180]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR)
	with ESMTP id AGF33153; Wed, 8 Dec 2004 20:24:02 -0800 (PST)
Message-ID: <41B7D361.8010105@cisco.com>
Date: Wed, 08 Dec 2004 23:24:01 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Jesske, R" <R.Jesske@t-com.net>
Subject: Re: [Sip] AW:  Calling Party's Category
References: <E7666D92C64C2845AEF12636FF94F952F97513@S4DE8PSAAGQ.blf.telekom.de>
In-Reply-To: <E7666D92C64C2845AEF12636FF94F952F97513@S4DE8PSAAGQ.blf.telekom.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Cc: An.Nguyen@ncs.gov, iptel@ietf.org, sip@ietf.org, taylor@nortelnetworks.com,
        oran@cisco.com, Mpierce1@aol.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: 7bit



Jesske, R wrote:

> Dear Tom, all,
> I see there are several questions with regard to the CPC. Our approach is to use it for billing, charge info and routing purposes.
> 
> Payphone:
> 1. Payphone Calls are routed in an other manner than normal calls

In what way are they routed differently?


> 2. Payphone Calls are billed differently compared with normal calls
> 3. The charge information shown to the user of the payphone is an other than for normal once
> 4. Based on the CPC a blocking of numbers (e.G premium rate or special destinations) can be performed
> 5. Special accounting mechanisms for free phone numbers are possible

I think its also worth pointing out that the general topic of 
"payphones" in sip is a complicated one, of which the cpc aspect - 
asserting the trait of being a payphone - is one of the easier ones. 
Figuring out a way to do the payments securely is a much more 
challenging issue.

I also wanted to note that if there are requirements for endpoint 
assertion of characteristics and capabilities, we have a spec for that 
too - namely rfc3840. The usage of SAML for doing the network asserted 
traits also seems right to me.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec  9 08:28:45 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20704
	for <sip-web-archive@ietf.org>; Thu, 9 Dec 2004 08:28:45 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcOSd-0004zh-2d
	for sip-web-archive@ietf.org; Thu, 09 Dec 2004 08:36:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcOHl-0006dG-Jk; Thu, 09 Dec 2004 08:24:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcOGE-0005q6-7A; Thu, 09 Dec 2004 08:23:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20483;
	Thu, 9 Dec 2004 08:23:09 -0500 (EST)
Received: from mail4.telekom.de ([195.243.210.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcON9-0004uk-VZ; Thu, 09 Dec 2004 08:30:23 -0500
Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP;
	Thu, 9 Dec 2004 14:22:14 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <YPPPP3PJ>; Thu, 9 Dec 2004 14:22:30 +0100
Message-Id: <E7666D92C64C2845AEF12636FF94F952F97559@S4DE8PSAAGQ.blf.telekom.de>
From: "Jesske, R" <R.Jesske@t-com.net>
To: jdrosen@cisco.com
Subject: AW: [Sip] AW:  Calling Party's Category
Date: Thu, 9 Dec 2004 14:22:26 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: An.Nguyen@ncs.gov, iptel@ietf.org, sip@ietf.org, taylor@nortelnetworks.com,
        oran@cisco.com, kmainwar@cisco.com, Mpierce1@aol.com
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81



> -----Ursprungliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
> Gesendet: Donnerstag, 9. Dezember 2004 05:24
> An: Jesske, Roland
> Cc: taylor@nortelnetworks.com; An.Nguyen@ncs.gov; sip@ietf.org;
> iptel@ietf.org; oran@cisco.com; Mpierce1@aol.com
> Betreff: Re: [Sip] AW: Calling Party's Category
> 
> 
> 
> 
> Jesske, R wrote:
> 
> > Dear Tom, all,
> > I see there are several questions with regard to the CPC. 
> Our approach is to use it for billing, charge info and 
> routing purposes.
> > 
> > Payphone:
> > 1. Payphone Calls are routed in an other manner than normal calls
> 
> In what way are they routed differently?

One of our main issues is interoperability between PSTN/ISDN and SIP/NGN. PSTN/ISDN use this indication also for routing.
In PSTN/ISDN the "data-call" can be only transferred over 64kbit/s trunks. This can be used for a efficient coos of the correct MGC/MG combination with the clearmode codec.

> 
> 
> > 2. Payphone Calls are billed differently compared with normal calls
> > 3. The charge information shown to the user of the payphone 
> is an other than for normal once
> > 4. Based on the CPC a blocking of numbers (e.G premium rate 
> or special destinations) can be performed
> > 5. Special accounting mechanisms for free phone numbers are possible
> 
> I think its also worth pointing out that the general topic of 
> "payphones" in sip is a complicated one, of which the cpc aspect - 
> asserting the trait of being a payphone - is one of the easier ones. 
> Figuring out a way to do the payments securely is a much more 
> challenging issue.
> 
> I also wanted to note that if there are requirements for endpoint 
> assertion of characteristics and capabilities, we have a spec 
> for that 
> too - namely rfc3840. The usage of SAML for doing the network 
> asserted 
> traits also seems right to me.

As Takuya said:  cpc parameter will be used with 
P-Asserted-Identity header. In this scenario, trust domains 
model described in RFC 3324 is enough solution for security 
and authorization issues. Anyway we will require cpc value to 
be asserted by the network as it is in ISUP.
> 
> Thanks,
> Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> jdrosen@cisco.com                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec  9 12:58:44 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15886
	for <sip-web-archive@ietf.org>; Thu, 9 Dec 2004 12:58:44 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcSfy-0002j0-JN
	for sip-web-archive@ietf.org; Thu, 09 Dec 2004 13:06:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcSXS-0004Kv-8g; Thu, 09 Dec 2004 12:57:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CcSPu-0002IL-NJ
	for sip@megatron.ietf.org; Thu, 09 Dec 2004 12:49:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14991
	for <sip@ietf.org>; Thu, 9 Dec 2004 12:49:24 -0500 (EST)
Received: from broadsoft.com ([204.200.197.133])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcSWt-0002W8-Ce
	for sip@ietf.org; Thu, 09 Dec 2004 12:56:42 -0500
Received: from brett1 (66.239.146.130.ptr.us.xo.net [66.239.146.130])
	(authenticated bits=0)
	by broadsoft.com (8.13.1/8.12.11) with ESMTP id iB9HnDwH030755
	for <sip@ietf.org>; Thu, 9 Dec 2004 12:49:17 -0500 (EST)
From: "Brett Tate" <brett@broadsoft.com>
To: "sip-ietf" <sip@ietf.org>
Date: Thu, 9 Dec 2004 12:53:42 -0500
Message-ID: <001701c4de18$059a82d0$a601a8c0@brett1>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] RFC 3261: 32 bit CSeq number
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: quoted-printable


I have recently observed that some vendors are reading RFC 3261 section
8.1.1.5's CSeq maximum value comments out of context.  They are =
interpreting
the statement to also apply to requests within dialogs.  They are not
noticing the text within sections 8 and 8.1 which indicate that these
subsections apply to requests outside of a dialog.  Is it possible to =
get
the sentence reworded for clarity within errata and/or a future bis?

RFC 3261 section 8.1.1.5:
"The sequence number value MUST be expressible as a 32-bit unsigned =
integer
and MUST be less than 2**31."



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec  9 15:19:46 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29962
	for <sip-web-archive@ietf.org>; Thu, 9 Dec 2004 15:19:46 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcUsT-0005xD-5H
	for sip-web-archive@ietf.org; Thu, 09 Dec 2004 15:27:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcUhP-0007EP-EL; Thu, 09 Dec 2004 15:15:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CcUcN-0004C7-GP
	for sip@megatron.ietf.org; Thu, 09 Dec 2004 15:10:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28769
	for <sip@ietf.org>; Thu, 9 Dec 2004 15:10:26 -0500 (EST)
Received: from host10.216.41.24.conversent.net ([216.41.24.10]
	helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcUjP-0005lf-T7 for sip@ietf.org; Thu, 09 Dec 2004 15:17:44 -0500
Received: from BPenfield2 [216.41.24.2] by acmepacket.com with ESMTP
	(SMTPD32-8.14) id A2CA209C004A; Thu, 09 Dec 2004 15:17:14 -0500
Message-ID: <001001c4de2b$07d472a0$f90b000a@BPenfield2>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "sip-ietf" <sip@ietf.org>, "Brett Tate" <brett@broadsoft.com>
References: <001701c4de18$059a82d0$a601a8c0@brett1>
Subject: Re: [Sip] RFC 3261: 32 bit CSeq number
Date: Thu, 9 Dec 2004 15:09:46 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit
Cc: sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit

Section 8.1.1.5 says:

   The CSeq header field serves as a way to identify and order
   transactions.  It consists of a sequence number and a method.  The
   method MUST match that of the request.  For non-REGISTER requests
   outside of a dialog, the sequence number value is arbitrary.  The
   sequence number value MUST be expressible as a 32-bit unsigned
   integer and MUST be less than 2**31.  As long as it follows the above
   guidelines, a client may use any mechanism it would like to select
   CSeq header field values.

The maximum value stated applies to ALL requests. The phrase "For
non-REGISTER requests outside of a dialog, the sequence number value is
arbitrary" refers to the requirement that REGISTER requests (for the same
Call-ID) and in-dialog requests must always have increasing CSeq numbers.
This phrase does not mean that in-dialog and REGISTER requests may exceed
the stated limit of less than 2**31.

In section 12.2.1.1, there is text that implies that the CSeq may be any
32-bit value, but this is non-normative illustrative text. The restriction
in 8.1.1.5 still applies.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com


----- Original Message ----- 
From: "Brett Tate" <brett@broadsoft.com>
To: "sip-ietf" <sip@ietf.org>
Sent: Thursday, December 09, 2004 12:53 PM
Subject: [Sip] RFC 3261: 32 bit CSeq number



I have recently observed that some vendors are reading RFC 3261 section
8.1.1.5's CSeq maximum value comments out of context.  They are interpreting
the statement to also apply to requests within dialogs.  They are not
noticing the text within sections 8 and 8.1 which indicate that these
subsections apply to requests outside of a dialog.  Is it possible to get
the sentence reworded for clarity within errata and/or a future bis?

RFC 3261 section 8.1.1.5:
"The sequence number value MUST be expressible as a 32-bit unsigned integer
and MUST be less than 2**31."



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec  9 15:28:26 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01086
	for <sip-web-archive@ietf.org>; Thu, 9 Dec 2004 15:28:26 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcV0p-00069l-E1
	for sip-web-archive@ietf.org; Thu, 09 Dec 2004 15:35:44 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcUrl-0005ml-Ib; Thu, 09 Dec 2004 15:26:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CcUjO-0008QO-8D
	for sip@megatron.ietf.org; Thu, 09 Dec 2004 15:17:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29772
	for <sip@ietf.org>; Thu, 9 Dec 2004 15:17:40 -0500 (EST)
Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcUqQ-0005un-6A
	for sip@ietf.org; Thu, 09 Dec 2004 15:24:59 -0500
Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93])
	by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	iB9KH9KX009378
	for <sip@ietf.org>; Thu, 9 Dec 2004 15:17:09 -0500 (EST)
Received: from sonusmail02.sonusnet.com (unverified) by sonusms1.sonusnet.com
	(Content Technologies SMTPRS 4.3.12) with ESMTP id
	<T6dc4d06fbb0a80205d3a4@sonusms1.sonusnet.com>; 
	Thu, 9 Dec 2004 15:17:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number
Date: Thu, 9 Dec 2004 15:17:09 -0500
Message-ID: <05AE95C39E8E2642AF9C04526EDAC4141D8A15@sonusmail02.sonusnet.com>
Thread-Topic: [Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number
Thread-Index: AcTeKxlA+s1ejvTFSUStuPl2IcJ70AAAK18g
From: "Bharrat, Shaun" <SBharrat@sonusnet.com>
To: "Bob Penfield" <bpenfield@acmepacket.com>, "sip-ietf" <sip@ietf.org>,
        "Brett Tate" <brett@broadsoft.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Content-Transfer-Encoding: quoted-printable
Cc: sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Content-Transfer-Encoding: quoted-printable

Bob:

Sorry, I'm confused. The initial CSEQ # for a dialog can be any
random number less than 2**31. Suppose that one picks 2**31 - 1
as the initial CSEQ. How can you send more than one packet on
the dialog without violating CSEQ < 2**31 ?

Cheers,
Shaun Bharrat
Sonus Networks



-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu]On Behalf Of Bob
Penfield
Sent: Thursday, December 09, 2004 3:10 PM
To: sip-ietf; Brett Tate
Cc: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number


Section 8.1.1.5 says:

   The CSeq header field serves as a way to identify and order
   transactions.  It consists of a sequence number and a method.  The
   method MUST match that of the request.  For non-REGISTER requests
   outside of a dialog, the sequence number value is arbitrary.  The
   sequence number value MUST be expressible as a 32-bit unsigned
   integer and MUST be less than 2**31.  As long as it follows the above
   guidelines, a client may use any mechanism it would like to select
   CSeq header field values.

The maximum value stated applies to ALL requests. The phrase "For
non-REGISTER requests outside of a dialog, the sequence number value is
arbitrary" refers to the requirement that REGISTER requests (for the =
same
Call-ID) and in-dialog requests must always have increasing CSeq =
numbers.
This phrase does not mean that in-dialog and REGISTER requests may =
exceed
the stated limit of less than 2**31.

In section 12.2.1.1, there is text that implies that the CSeq may be any
32-bit value, but this is non-normative illustrative text. The =
restriction
in 8.1.1.5 still applies.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com


----- Original Message -----=20
From: "Brett Tate" <brett@broadsoft.com>
To: "sip-ietf" <sip@ietf.org>
Sent: Thursday, December 09, 2004 12:53 PM
Subject: [Sip] RFC 3261: 32 bit CSeq number



I have recently observed that some vendors are reading RFC 3261 section
8.1.1.5's CSeq maximum value comments out of context.  They are =
interpreting
the statement to also apply to requests within dialogs.  They are not
noticing the text within sections 8 and 8.1 which indicate that these
subsections apply to requests outside of a dialog.  Is it possible to =
get
the sentence reworded for clarity within errata and/or a future bis?

RFC 3261 section 8.1.1.5:
"The sequence number value MUST be expressible as a 32-bit unsigned =
integer
and MUST be less than 2**31."



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec  9 15:44:52 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02500
	for <sip-web-archive@ietf.org>; Thu, 9 Dec 2004 15:44:52 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcVGk-0006U2-Ss
	for sip-web-archive@ietf.org; Thu, 09 Dec 2004 15:52:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcV6A-0004n7-ET; Thu, 09 Dec 2004 15:41:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CcV07-0001cw-6j
	for sip@megatron.ietf.org; Thu, 09 Dec 2004 15:34:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01581
	for <sip@ietf.org>; Thu, 9 Dec 2004 15:34:57 -0500 (EST)
Received: from broadsoft.com ([204.200.197.133])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcV7A-0006IS-5p
	for sip@ietf.org; Thu, 09 Dec 2004 15:42:16 -0500
Received: from brett1 (66.239.146.130.ptr.us.xo.net [66.239.146.130])
	(authenticated bits=0)
	by broadsoft.com (8.13.1/8.12.11) with ESMTP id iB9KYbkJ041397;
	Thu, 9 Dec 2004 15:34:47 -0500 (EST)
From: "Brett Tate" <brett@broadsoft.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>, "'sip-ietf'" <sip@ietf.org>
Subject: RE: [Sip] RFC 3261: 32 bit CSeq number
Date: Thu, 9 Dec 2004 15:39:39 -0500
Message-ID: <001a01c4de2f$389c40d0$a601a8c0@brett1>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <001001c4de2b$07d472a0$f90b000a@BPenfield2>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: quoted-printable
Cc: sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: quoted-printable

> Section 8.1.1.5 says:
>=20
>    The CSeq header field serves as a way to identify and order
>    transactions.  It consists of a sequence number and a method.  The
>    method MUST match that of the request.  For non-REGISTER requests
>    outside of a dialog, the sequence number value is arbitrary.  The
>    sequence number value MUST be expressible as a 32-bit unsigned
>    integer and MUST be less than 2**31.  As long as it=20
> follows the above
>    guidelines, a client may use any mechanism it would like to select
>    CSeq header field values.
>=20
> The maximum value stated applies to ALL requests. The phrase=20
> "For non-REGISTER requests outside of a dialog, the sequence=20
> number value is arbitrary" refers to the requirement that=20
> REGISTER requests (for the same
> Call-ID) and in-dialog requests must always have increasing=20
> CSeq numbers. This phrase does not mean that in-dialog and=20
> REGISTER requests may exceed the stated limit of less than 2**31.
>=20
> In section 12.2.1.1, there is text that implies that the CSeq=20
> may be any 32-bit value, but this is non-normative=20
> illustrative text. The restriction in 8.1.1.5 still applies.


RFC 3261 Section 8 clearly indicates the context of its subsections: "In
this section, we discuss the method-independent rules for UAC and UAS
behavior when processing requests that are outside of a dialog. This
includes, of course, the requests which themselves establish a dialog."

And section 8.1 only contains the following text: "This section covers =
UAC
behavior outside of a dialog."  This clearly indicates its subsections
(including 8.1.1.5) do not specifically apply to requests within a =
dialog.


Section 20.16 defines the normative text for max CSeq: "A CSeq header =
field
in a request contains a single decimal sequence number and the request
method.  The sequence number MUST be expressible as a 32-bit unsigned
integer."  The normative text within section 8.1.1.5 only reduces it 31 =
bits
for requests outside of a dialog.  The reason requests that create a =
dialog
have a max of 31 bits is to allow another 2 million requests within the
dialog before exceeding the 32 bit maximum.


Section 12.2.1.1 discusses how the full 32 bits can used:

"With a length of 32 bits, a client could generate, within a single =
call,
one request a second for about 136 years before needing to wrap around.  =
The
initial value of the sequence number is chosen so that subsequent =
requests
within the same call will not wrap around.  A non-zero initial value =
allows
clients to use a time-based initial sequence number.  A client could, =
for
example, choose the 31 most significant bits of a 32-bit second clock as =
an
initial sequence number."




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec  9 16:54:27 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15364
	for <sip-web-archive@ietf.org>; Thu, 9 Dec 2004 16:54:27 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcWM6-0002Gr-HM
	for sip-web-archive@ietf.org; Thu, 09 Dec 2004 17:01:47 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcW6n-0001Ul-76; Thu, 09 Dec 2004 16:45:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CcVOO-0006YW-NI
	for sip@megatron.ietf.org; Thu, 09 Dec 2004 16:00:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03582
	for <sip@ietf.org>; Thu, 9 Dec 2004 16:00:03 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcVVR-0006we-OV
	for sip@ietf.org; Thu, 09 Dec 2004 16:07:22 -0500
Received: from [192.168.0.108] (adsl-209-30-33-13.dsl.rcsntx.swbell.net
	[209.30.33.13]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iB9KxjI6028713
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 9 Dec 2004 14:59:47 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <41B8BCBB.4090501@nostrum.com>
Date: Thu, 09 Dec 2004 14:59:39 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bob Penfield <bpenfield@acmepacket.com>
Subject: Re: [Sip] RFC 3261: 32 bit CSeq number
References: <001701c4de18$059a82d0$a601a8c0@brett1>
	<001001c4de2b$07d472a0$f90b000a@BPenfield2>
In-Reply-To: <001001c4de2b$07d472a0$f90b000a@BPenfield2>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: 7bit
Cc: sip-ietf <sip@ietf.org>, sip-implementors@cs.columbia.edu,
        Brett Tate <brett@broadsoft.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Content-Transfer-Encoding: 7bit

Okay, so here's an existence proof of at least one person who has been 
participating in SIP-related standardization for at least 3.5 years 
being confused about the intention of the CSeq range. If we can't even 
agree amongst ourselves, there's no hope that implementors will come 
away with a consistent view. That's a powerful argument that 
clarification is in order.

(I'm not necessarily saying that the party in error is Bob or Brett, 
simply that both have been at this for a while, and have read 3261 to 
mean different things. That said, I'm pretty sure that the intention is 
that CSeq values can go all the way to 2**32 inside a dialog.)

/a

Bob Penfield wrote:

>Section 8.1.1.5 says:
>
>   The CSeq header field serves as a way to identify and order
>   transactions.  It consists of a sequence number and a method.  The
>   method MUST match that of the request.  For non-REGISTER requests
>   outside of a dialog, the sequence number value is arbitrary.  The
>   sequence number value MUST be expressible as a 32-bit unsigned
>   integer and MUST be less than 2**31.  As long as it follows the above
>   guidelines, a client may use any mechanism it would like to select
>   CSeq header field values.
>
>The maximum value stated applies to ALL requests. The phrase "For
>non-REGISTER requests outside of a dialog, the sequence number value is
>arbitrary" refers to the requirement that REGISTER requests (for the same
>Call-ID) and in-dialog requests must always have increasing CSeq numbers.
>This phrase does not mean that in-dialog and REGISTER requests may exceed
>the stated limit of less than 2**31.
>
>In section 12.2.1.1, there is text that implies that the CSeq may be any
>32-bit value, but this is non-normative illustrative text. The restriction
>in 8.1.1.5 still applies.
>
>cheers,
>(-:bob
>
>Robert F. Penfield
>Chief Software Architect
>Acme Packet, Inc.
>130 New Boston Street
>Woburn, MA 01801
>bpenfield@acmepacket.com
>
>
>----- Original Message ----- 
>From: "Brett Tate" <brett@broadsoft.com>
>To: "sip-ietf" <sip@ietf.org>
>Sent: Thursday, December 09, 2004 12:53 PM
>Subject: [Sip] RFC 3261: 32 bit CSeq number
>
>
>
>I have recently observed that some vendors are reading RFC 3261 section
>8.1.1.5's CSeq maximum value comments out of context.  They are interpreting
>the statement to also apply to requests within dialogs.  They are not
>noticing the text within sections 8 and 8.1 which indicate that these
>subsections apply to requests outside of a dialog.  Is it possible to get
>the sentence reworded for clarity within errata and/or a future bis?
>
>RFC 3261 section 8.1.1.5:
>"The sequence number value MUST be expressible as a 32-bit unsigned integer
>and MUST be less than 2**31."
>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
>  
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec  9 17:45:44 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23932
	for <sip-web-archive@ietf.org>; Thu, 9 Dec 2004 17:45:44 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcX9k-0004kB-N6
	for sip-web-archive@ietf.org; Thu, 09 Dec 2004 17:53:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcWxS-0004Fo-Nr; Thu, 09 Dec 2004 17:40:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CcWol-0000Kn-QD
	for sip@megatron.ietf.org; Thu, 09 Dec 2004 17:31:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22614
	for <sip@ietf.org>; Thu, 9 Dec 2004 17:31:21 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcWvp-0004Lv-PI
	for sip@ietf.org; Thu, 09 Dec 2004 17:38:42 -0500
Received: from [10.10.10.141] (pool-138-89-35-120.mad.east.verizon.net
	[138.89.35.120]) (authenticated bits=0)
	by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iB9MVx4L031647
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 9 Dec 2004 16:32:03 -0600
In-Reply-To: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FFF@hadron.jnpr.net>
References: <F07F17B61B7FF545BC7D7E4BFBE15D2A473FFF@hadron.jnpr.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <08427279-4A32-11D9-BBA2-000D93594350@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] Doubts in SIP/SDP
Date: Thu, 9 Dec 2004 16:31:13 -0600
To: "Anil Bollineni" <ABollineni@juniper.net>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 7bit


BTW, this is a lovely "sip-implementors" list question.

Answers herein are my opinion, and may not mesh with some particularly 
strict interpretations. On the other hand, one can refer to the Postel 
axiom "be liberal with what you accept" (or however he said that . . .)

More detailed procedures are available in 
draft-ietf-sipping-early-media-02.txt, which I believe has been 
approved by the IESG and is in the RFC Editor queue.

On Dec 7, 2004, at 6:10 PM, Anil Bollineni wrote:

> Hi,
>   Thanks for the response. I have a basic question, considering 3 
> views.
>
> 1. Suppose terminating endpoint does not support 183, and sends the
> early media for IVR, should  UAC, play the media treated as if early
> media.
>

yes.

> 2. Any case the terminating endpoint must support 183 and send the 
> media
> after it sends. The 100rel is optional, in this case the sequence of 
> 183
> and early media is not guaranteed. Should UAC prepare media 
> irrespective
> of call progress message?
>

The UAC should play any media it receives that is consistent with the 
SDP it offered in the INVITE.

The exception to this case is described in the early media draft:

         Note that, in some situations, the UAC does need to receive
         the answer before being able to play any media. UAs in such
         a situation (e.g., QoS, media authorization or media
         encryption is required) use preconditions to avoid media
         clipping.

The use of preconditions is discussed in RFC 3312.

> 3. In case of 100Rel calling UA requires the option 100rel, should
> terminating endpoint MUST send always after PRACK is received?
>

That's debatable. One might be inclined to suspect that the calling UA 
has issues with "really early media" in this case, and the UAS SHOULD 
hold off until receiving the PRACK. I don't know that MUST applies, as 
one can reasonably expect that SOME UASs might not delay, so the 
calling UA MUST be prepared to deal with the consequences of a called 
UA that responds with media before sending an SDP answer.



> Specifically, if we want deploy a firewall between originating and
> terminating endpoints, should we allow early media after INVITE without
> 183 is being seen?
>

yes.


--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec  9 22:13:21 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14440
	for <sip-web-archive@ietf.org>; Thu, 9 Dec 2004 22:13:21 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcbKl-0001Qi-Sc
	for sip-web-archive@ietf.org; Thu, 09 Dec 2004 22:20:44 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ccb75-0007Rf-FY; Thu, 09 Dec 2004 22:06:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccb39-0006NU-N1
	for sip@megatron.ietf.org; Thu, 09 Dec 2004 22:02:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13647
	for <sip@ietf.org>; Thu, 9 Dec 2004 22:02:30 -0500 (EST)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcbAD-0001Fl-22
	for sip@ietf.org; Thu, 09 Dec 2004 22:09:52 -0500
Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id iBA31RD24822; Thu, 9 Dec 2004 22:01:27 -0500 (EST)
Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <YFGT3VQL>; Thu, 9 Dec 2004 22:01:28 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF012851E7@zrc2hxm0.corp.nortel.com>
From: "Francois Audet" <audet@nortelnetworks.com>
To: "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Anil Bollineni'"
	<ABollineni@juniper.net>
Subject: RE: [Sip] Doubts in SIP/SDP
Date: Thu, 9 Dec 2004 22:01:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838
Cc: "'sip@ietf.org'" <sip@ietf.org>,
        "'sip-implementors@cs.columbia.edu'" <sip-implementors@cs.columbia.edu>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1946463459=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 343d06d914165ffd9d590a64755216ca

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1946463459==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4DE64.80A3A811"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4DE64.80A3A811
Content-Type: text/plain

Of course with forking, this gets really interesting.

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On 
> Behalf Of Dean Willis
> Sent: Thursday, December 09, 2004 14:31
> To: Anil Bollineni
> Cc: sip@ietf.org; sip-implementors@cs.columbia.edu
> Subject: Re: [Sip] Doubts in SIP/SDP
> 
> 
> 
> BTW, this is a lovely "sip-implementors" list question.
> 
> Answers herein are my opinion, and may not mesh with some 
> particularly 
> strict interpretations. On the other hand, one can refer to 
> the Postel 
> axiom "be liberal with what you accept" (or however he said 
> that . . .)
> 
> More detailed procedures are available in 
> draft-ietf-sipping-early-media-02.txt, which I believe has been 
> approved by the IESG and is in the RFC Editor queue.
> 
> On Dec 7, 2004, at 6:10 PM, Anil Bollineni wrote:
> 
> > Hi,
> >   Thanks for the response. I have a basic question, considering 3
> > views.
> >
> > 1. Suppose terminating endpoint does not support 183, and sends the 
> > early media for IVR, should  UAC, play the media treated as 
> if early 
> > media.
> >
> 
> yes.
> 
> > 2. Any case the terminating endpoint must support 183 and send the
> > media
> > after it sends. The 100rel is optional, in this case the 
> sequence of 
> > 183
> > and early media is not guaranteed. Should UAC prepare media 
> > irrespective
> > of call progress message?
> >
> 
> The UAC should play any media it receives that is consistent with the 
> SDP it offered in the INVITE.
> 
> The exception to this case is described in the early media draft:
> 
>          Note that, in some situations, the UAC does need to receive
>          the answer before being able to play any media. UAs in such
>          a situation (e.g., QoS, media authorization or media
>          encryption is required) use preconditions to avoid media
>          clipping.
> 
> The use of preconditions is discussed in RFC 3312.
> 
> > 3. In case of 100Rel calling UA requires the option 100rel, should
> > terminating endpoint MUST send always after PRACK is received?
> >
> 
> That's debatable. One might be inclined to suspect that the 
> calling UA 
> has issues with "really early media" in this case, and the UAS SHOULD 
> hold off until receiving the PRACK. I don't know that MUST 
> applies, as 
> one can reasonably expect that SOME UASs might not delay, so the 
> calling UA MUST be prepared to deal with the consequences of a called 
> UA that responds with media before sending an SDP answer.
> 
> 
> 
> > Specifically, if we want deploy a firewall between originating and
> > terminating endpoints, should we allow early media after 
> INVITE without
> > 183 is being seen?
> >
> 
> yes.
> 
> 
> --
> Dean
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
> 

------_=_NextPart_001_01C4DE64.80A3A811
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Sip] Doubts in SIP/SDP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Of course with forking, this gets really =
interesting.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: sip-bounces@ietf.org [<A =
HREF=3D"mailto:sip-bounces@ietf.org">mailto:sip-bounces@ietf.org</A>] =
On </FONT>
<BR><FONT SIZE=3D2>&gt; Behalf Of Dean Willis</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, December 09, 2004 14:31</FONT>
<BR><FONT SIZE=3D2>&gt; To: Anil Bollineni</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: sip@ietf.org; =
sip-implementors@cs.columbia.edu</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Sip] Doubts in SIP/SDP</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; BTW, this is a lovely =
&quot;sip-implementors&quot; list question.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Answers herein are my opinion, and may not mesh =
with some </FONT>
<BR><FONT SIZE=3D2>&gt; particularly </FONT>
<BR><FONT SIZE=3D2>&gt; strict interpretations. On the other hand, one =
can refer to </FONT>
<BR><FONT SIZE=3D2>&gt; the Postel </FONT>
<BR><FONT SIZE=3D2>&gt; axiom &quot;be liberal with what you =
accept&quot; (or however he said </FONT>
<BR><FONT SIZE=3D2>&gt; that . . .)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; More detailed procedures are available in =
</FONT>
<BR><FONT SIZE=3D2>&gt; draft-ietf-sipping-early-media-02.txt, which I =
believe has been </FONT>
<BR><FONT SIZE=3D2>&gt; approved by the IESG and is in the RFC Editor =
queue.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Dec 7, 2004, at 6:10 PM, Anil Bollineni =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Thanks for the response. I =
have a basic question, considering 3</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; views.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1. Suppose terminating endpoint does not =
support 183, and sends the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; early media for IVR, should&nbsp; UAC, =
play the media treated as </FONT>
<BR><FONT SIZE=3D2>&gt; if early </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; media.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; yes.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2. Any case the terminating endpoint must =
support 183 and send the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; media</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; after it sends. The 100rel is optional, in =
this case the </FONT>
<BR><FONT SIZE=3D2>&gt; sequence of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 183</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and early media is not guaranteed. Should =
UAC prepare media </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; irrespective</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of call progress message?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The UAC should play any media it receives that =
is consistent with the </FONT>
<BR><FONT SIZE=3D2>&gt; SDP it offered in the INVITE.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The exception to this case is described in the =
early media draft:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Note that, in some situations, the UAC does need to receive</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
answer before being able to play any media. UAs in such</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a =
situation (e.g., QoS, media authorization or media</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
encryption is required) use preconditions to avoid media</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
clipping.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The use of preconditions is discussed in RFC =
3312.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 3. In case of 100Rel calling UA requires =
the option 100rel, should</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; terminating endpoint MUST send always =
after PRACK is received?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; That's debatable. One might be inclined to =
suspect that the </FONT>
<BR><FONT SIZE=3D2>&gt; calling UA </FONT>
<BR><FONT SIZE=3D2>&gt; has issues with &quot;really early media&quot; =
in this case, and the UAS SHOULD </FONT>
<BR><FONT SIZE=3D2>&gt; hold off until receiving the PRACK. I don't =
know that MUST </FONT>
<BR><FONT SIZE=3D2>&gt; applies, as </FONT>
<BR><FONT SIZE=3D2>&gt; one can reasonably expect that SOME UASs might =
not delay, so the </FONT>
<BR><FONT SIZE=3D2>&gt; calling UA MUST be prepared to deal with the =
consequences of a called </FONT>
<BR><FONT SIZE=3D2>&gt; UA that responds with media before sending an =
SDP answer.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Specifically, if we want deploy a firewall =
between originating and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; terminating endpoints, should we allow =
early media after </FONT>
<BR><FONT SIZE=3D2>&gt; INVITE without</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 183 is being seen?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; yes.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Dean</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; This list is for NEW development of the core =
SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; Use sip-implementors@cs.columbia.edu for =
questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; Use sipping@ietf.org for new developments on =
the application of sip</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4DE64.80A3A811--


--===============1946463459==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1946463459==--



From sip-bounces@ietf.org  Fri Dec 10 08:48:05 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14676
	for <sip-web-archive@ietf.org>; Fri, 10 Dec 2004 08:48:05 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CclF7-00059B-3u
	for sip-web-archive@ietf.org; Fri, 10 Dec 2004 08:55:33 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cckxj-0000am-9d; Fri, 10 Dec 2004 08:37:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CcksC-0007SZ-WB
	for sip@megatron.ietf.org; Fri, 10 Dec 2004 08:31:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13461
	for <sip@ietf.org>; Fri, 10 Dec 2004 08:31:51 -0500 (EST)
Received: from host10.216.41.24.conversent.net ([216.41.24.10]
	helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CckzO-0004pu-SG for sip@ietf.org; Fri, 10 Dec 2004 08:39:19 -0500
Received: from PTimmons1 [216.41.24.2] by acmepacket.com with ESMTP
	(SMTPD32-8.14) id A6E01E540058; Fri, 10 Dec 2004 08:38:40 -0500
From: "Patrick Timmons" <ptimmons@acmepacket.com>
To: "'Bharrat, Shaun'" <SBharrat@sonusnet.com>,
        "'Bob Penfield'" <bpenfield@acmepacket.com>,
        "'sip-ietf'" <sip@ietf.org>, "'Brett Tate'" <brett@broadsoft.com>
Subject: RE: [Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number
Date: Fri, 10 Dec 2004 08:33:14 -0500
Organization: acmepacket.com
Message-ID: <001801c4debc$d015bd00$800101df@PTimmons1>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <05AE95C39E8E2642AF9C04526EDAC4141D8A15@sonusmail02.sonusnet.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Content-Transfer-Encoding: 7bit
Cc: sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ptimmons@acmepacket.com
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Content-Transfer-Encoding: 7bit

Below is my interpretation; please feel free to correct me where I am in
error.

Each UA in a dialog has its own locally generated CSeq number.  These
initial, locally generated CSeq numbers MUST be less than 2**31.  Each
subsequent transaction within a dialog will increment the CSeq value by
one.  By choosing a starting value less than 2**31, but allowing all
values up to 32 bits (2**32), this affords each UA over two billion
(2**32 - 2**31) unique, legal values.  This is the rationale behind the
illustrative text in section 12.2.1.1 ("one request a second for about
136 years before needing to wrap around").

My own illustrative example:
A UA (the "subscriber") sends a SUBSCRIBE to a subscription server.  The
SUBSCRIBE is not inside an existing dialog, so the subscriber constructs
the CSeq in this request in accordance with the requirements of 8.1.1.5
-- that is, this value MUST be less than 2**31.  The subscription server
sends a 2xx response, and a dialog is established.  The subscription
server, in accord with RFC 3265, immediately sends a NOTIFY to the
subscriber.  This being the first in-dialog request generated by the
subscription server, it has no locally generated CSeq value.  Following
the requirement set forth in 12.2.1.1 ("If the local sequence number is
empty, an initial value MUST be chosen using the guidelines of Section
8.1.1.5"), it also MUST choose an initial CSeq less than 2**31.  With
these values established, the subscriber and subscription server will
send in-dialog requests, incrementing the CSeq values with each new
transaction.  Thus both the subscriber and the subscription server have
the luxury of over two billion valid CSeq values to use going forward --
mitigating the possibility of wrapping the 32 bit range of legal values.

The wording of the specification is arguably a bit fuzzy, but the intent
seems clear: prevent CSeq wrapping by forcing each UA in a dialog to
choose sane initial values.

Pat Timmons
Acme Packet, Inc.

-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Bharrat,
Shaun
Sent: Thursday, December 09, 2004 3:17 PM
To: Bob Penfield; sip-ietf; Brett Tate
Cc: sip-implementors@cs.columbia.edu
Subject: RE: [Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number


Bob:

Sorry, I'm confused. The initial CSEQ # for a dialog can be any
random number less than 2**31. Suppose that one picks 2**31 - 1
as the initial CSEQ. How can you send more than one packet on
the dialog without violating CSEQ < 2**31 ?

Cheers,
Shaun Bharrat
Sonus Networks



-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu]On Behalf Of Bob
Penfield
Sent: Thursday, December 09, 2004 3:10 PM
To: sip-ietf; Brett Tate
Cc: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number


Section 8.1.1.5 says:

   The CSeq header field serves as a way to identify and order
   transactions.  It consists of a sequence number and a method.  The
   method MUST match that of the request.  For non-REGISTER requests
   outside of a dialog, the sequence number value is arbitrary.  The
   sequence number value MUST be expressible as a 32-bit unsigned
   integer and MUST be less than 2**31.  As long as it follows the above
   guidelines, a client may use any mechanism it would like to select
   CSeq header field values.

The maximum value stated applies to ALL requests. The phrase "For
non-REGISTER requests outside of a dialog, the sequence number value is
arbitrary" refers to the requirement that REGISTER requests (for the
same
Call-ID) and in-dialog requests must always have increasing CSeq
numbers.
This phrase does not mean that in-dialog and REGISTER requests may
exceed
the stated limit of less than 2**31.

In section 12.2.1.1, there is text that implies that the CSeq may be any
32-bit value, but this is non-normative illustrative text. The
restriction
in 8.1.1.5 still applies.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com


----- Original Message ----- 
From: "Brett Tate" <brett@broadsoft.com>
To: "sip-ietf" <sip@ietf.org>
Sent: Thursday, December 09, 2004 12:53 PM
Subject: [Sip] RFC 3261: 32 bit CSeq number



I have recently observed that some vendors are reading RFC 3261 section
8.1.1.5's CSeq maximum value comments out of context.  They are
interpreting
the statement to also apply to requests within dialogs.  They are not
noticing the text within sections 8 and 8.1 which indicate that these
subsections apply to requests outside of a dialog.  Is it possible to
get
the sentence reworded for clarity within errata and/or a future bis?

RFC 3261 section 8.1.1.5:
"The sequence number value MUST be expressible as a 32-bit unsigned
integer
and MUST be less than 2**31."



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Fri Dec 10 08:59:43 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15446
	for <sip-web-archive@ietf.org>; Fri, 10 Dec 2004 08:59:43 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CclQN-0005Op-5A
	for sip-web-archive@ietf.org; Fri, 10 Dec 2004 09:07:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ccl9F-0002Vy-SP; Fri, 10 Dec 2004 08:49:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccl7X-0001lA-1p
	for sip@megatron.ietf.org; Fri, 10 Dec 2004 08:47:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14644
	for <sip@ietf.org>; Fri, 10 Dec 2004 08:47:41 -0500 (EST)
Received: from host10.216.41.24.conversent.net ([216.41.24.10]
	helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CclEj-00058F-CT for sip@ietf.org; Fri, 10 Dec 2004 08:55:09 -0500
Received: from BPenfield2 [216.41.24.2] by acmepacket.com with ESMTP
	(SMTPD32-8.14) id AAA11E8A0058; Fri, 10 Dec 2004 08:54:41 -0500
Message-ID: <007f01c4debe$bf448db0$f90b000a@BPenfield2>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Adam Roach" <adam@nostrum.com>
References: <001701c4de18$059a82d0$a601a8c0@brett1><001001c4de2b$07d472a0$f90b000a@BPenfield2>
	<41B8BCBB.4090501@nostrum.com>
Subject: Re: [Sip] RFC 3261: 32 bit CSeq number
Date: Fri, 10 Dec 2004 08:47:10 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Content-Transfer-Encoding: 7bit
Cc: sip-ietf <sip@ietf.org>, sip-implementors@cs.columbia.edu,
        Brett Tate <brett@broadsoft.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Content-Transfer-Encoding: 7bit

After further study, I now agree with Brett's and Adam's interpretation that
the CSeq within a dialog may be any 32-bit number (0 thru (2**32-1)). I also
agree that clarification is in order since coming to that conclusion
required studying text from at least 3 different locations in 3261.

I apologize for adding to the confusion.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com

----- Original Message ----- 
From: "Adam Roach" <adam@nostrum.com>
To: "Bob Penfield" <bpenfield@acmepacket.com>
Cc: "sip-ietf" <sip@ietf.org>; <sip-implementors@cs.columbia.edu>; "Brett
Tate" <brett@broadsoft.com>
Sent: Thursday, December 09, 2004 3:59 PM
Subject: Re: [Sip] RFC 3261: 32 bit CSeq number


> Okay, so here's an existence proof of at least one person who has been
> participating in SIP-related standardization for at least 3.5 years
> being confused about the intention of the CSeq range. If we can't even
> agree amongst ourselves, there's no hope that implementors will come
> away with a consistent view. That's a powerful argument that
> clarification is in order.
>
> (I'm not necessarily saying that the party in error is Bob or Brett,
> simply that both have been at this for a while, and have read 3261 to
> mean different things. That said, I'm pretty sure that the intention is
> that CSeq values can go all the way to 2**32 inside a dialog.)
>
> /a
>
> Bob Penfield wrote:
>
> >Section 8.1.1.5 says:
> >
> >   The CSeq header field serves as a way to identify and order
> >   transactions.  It consists of a sequence number and a method.  The
> >   method MUST match that of the request.  For non-REGISTER requests
> >   outside of a dialog, the sequence number value is arbitrary.  The
> >   sequence number value MUST be expressible as a 32-bit unsigned
> >   integer and MUST be less than 2**31.  As long as it follows the above
> >   guidelines, a client may use any mechanism it would like to select
> >   CSeq header field values.
> >
> >The maximum value stated applies to ALL requests. The phrase "For
> >non-REGISTER requests outside of a dialog, the sequence number value is
> >arbitrary" refers to the requirement that REGISTER requests (for the same
> >Call-ID) and in-dialog requests must always have increasing CSeq numbers.
> >This phrase does not mean that in-dialog and REGISTER requests may exceed
> >the stated limit of less than 2**31.
> >
> >In section 12.2.1.1, there is text that implies that the CSeq may be any
> >32-bit value, but this is non-normative illustrative text. The
restriction
> >in 8.1.1.5 still applies.
> >
> >cheers,
> >(-:bob
> >
> >Robert F. Penfield
> >Chief Software Architect
> >Acme Packet, Inc.
> >130 New Boston Street
> >Woburn, MA 01801
> >bpenfield@acmepacket.com
> >
> >
> >----- Original Message ----- 
> >From: "Brett Tate" <brett@broadsoft.com>
> >To: "sip-ietf" <sip@ietf.org>
> >Sent: Thursday, December 09, 2004 12:53 PM
> >Subject: [Sip] RFC 3261: 32 bit CSeq number
> >
> >
> >
> >I have recently observed that some vendors are reading RFC 3261 section
> >8.1.1.5's CSeq maximum value comments out of context.  They are
interpreting
> >the statement to also apply to requests within dialogs.  They are not
> >noticing the text within sections 8 and 8.1 which indicate that these
> >subsections apply to requests outside of a dialog.  Is it possible to get
> >the sentence reworded for clarity within errata and/or a future bis?
> >
> >RFC 3261 section 8.1.1.5:
> >"The sequence number value MUST be expressible as a 32-bit unsigned
integer
> >and MUST be less than 2**31."
> >
> >
> >
> >_______________________________________________
> >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >This list is for NEW development of the core SIP Protocol
> >Use sip-implementors@cs.columbia.edu for questions on current sip
> >Use sipping@ietf.org for new developments on the application of sip
> >
> >
> >
> >
> >_______________________________________________
> >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >This list is for NEW development of the core SIP Protocol
> >Use sip-implementors@cs.columbia.edu for questions on current sip
> >Use sipping@ietf.org for new developments on the application of sip
> >
> >
> >
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
>



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Fri Dec 10 10:20:17 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22238
	for <sip-web-archive@ietf.org>; Fri, 10 Dec 2004 10:20:17 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcmgL-0006zi-Mb
	for sip-web-archive@ietf.org; Fri, 10 Dec 2004 10:27:46 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcmUN-00089P-Px; Fri, 10 Dec 2004 10:15:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CcmKE-0004HL-3A
	for sip@megatron.ietf.org; Fri, 10 Dec 2004 10:04:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20343
	for <sip@ietf.org>; Fri, 10 Dec 2004 10:04:52 -0500 (EST)
Received: from smail3.alcatel.fr ([194.133.58.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcmRP-0006hl-HP
	for sip@ietf.org; Fri, 10 Dec 2004 10:12:21 -0500
Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr
	[139.54.130.250])
	by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id iBAF4ErV013369
	for <sip@ietf.org>; Fri, 10 Dec 2004 16:04:14 +0100
Received: from [139.54.130.68] (nx0068.nextenso.alcatel.fr [139.54.130.68])
	by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id
	iBAG08fp021328 for <sip@ietf.org>; Fri, 10 Dec 2004 17:00:08 +0100
Message-ID: <41B9BB14.1040902@nextenso.com>
Date: Fri, 10 Dec 2004 16:04:52 +0100
From: Thomas Froment <Thomas.Froment@nextenso.com>
Organization: Nextenso
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: fr-FR, en, zh
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-yoursite-MailScanner-Information: Please contact the ISP for more information
X-yoursite-MailScanner: Found to be clean
X-Alcanet-MTA-scanned-and-authorized: yes
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Subject: [Sip] RFC 3263 (NAPTR/SRV) procedure question on "TARGET"
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit

In section 4 of RFC 3263 (Client usage for Locating SIP Servers):
it is written:

We define TARGET as the value of the maddr parameter of the URI, if 
present, otherwise, the host value of the hostport component of the URI.

THEN,
in section 4.1: if no transport protocol is specified, but the TARGET is 
a numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP 
for a SIPS URI.
Similarly, if no transport protocol is specified, and the TARGET is not 
numeric, but an explicit port is provided, the client SHOULD use UDP for 
a SIP URI, and TCP for a SIPS URI

Ok, no question with that, but just after that we have the opposite case:

Otherwise, if no transport protocol or port is specified, and the target 
is not a numeric IP address,
the client SHOULD perform a NAPTR query *for the domain in the URI*

My question: should we perform a NAPTR query for the domain in the 
*(Request) URI* or in the *TARGET* ?
because the maddr parameter (i.e. the TARGET if maddr exists) is not a 
numeric IP Address BUT the Request URI may still be an IP Address
at this step of the algorithm.

any help welcome,

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Fri Dec 10 13:14:40 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03850
	for <sip-web-archive@ietf.org>; Fri, 10 Dec 2004 13:14:40 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CcpP8-0001yD-SG
	for sip-web-archive@ietf.org; Fri, 10 Dec 2004 13:22:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CcpBL-0002vo-Q3; Fri, 10 Dec 2004 13:07:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccp6F-0001xC-L7
	for sip@megatron.ietf.org; Fri, 10 Dec 2004 13:02:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02848
	for <sip@ietf.org>; Fri, 10 Dec 2004 13:02:36 -0500 (EST)
Received: from broadsoft.com ([204.200.197.133])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcpDT-0001hh-62
	for sip@ietf.org; Fri, 10 Dec 2004 13:10:08 -0500
Received: from brett1 (66.239.146.130.ptr.us.xo.net [66.239.146.130])
	(authenticated bits=0)
	by broadsoft.com (8.13.1/8.12.11) with ESMTP id iBAI2PY5091983;
	Fri, 10 Dec 2004 13:02:29 -0500 (EST)
From: "Brett Tate" <brett@broadsoft.com>
To: <ptimmons@acmepacket.com>, "'sip-ietf'" <sip@ietf.org>
Subject: RE: [Sip-implementors] Re: [Sip] RFC 3261: 32 bit CSeq number
Date: Fri, 10 Dec 2004 13:06:54 -0500
Message-ID: <000901c4dee3$082680a0$a601a8c0@brett1>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
In-Reply-To: <001801c4debc$d015bd00$800101df@PTimmons1>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: quoted-printable
Cc: sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: quoted-printable

> The wording of the specification is=20
> arguably a bit fuzzy, but the intent=20
> seems clear: prevent CSeq wrapping by=20
> forcing each UA in a dialog to choose=20
> sane initial values.

I agree that a UA should choose a sane initial value.  Should a UAS =
return a
400 response, when it thinks that the UAC provided a cseq value between
2**31 and (2**32 - 1) when it should not have done so?

Shaun's example of choosing a cseq with (2**31 - 1) produces an =
interesting
situation.  Because of the MUST wording, does incrementing the cseq to =
2**31
and resubmitting the request because 401, 407, 422, etcetera produce a
protocol violation?  The UAC was aware of the prior cseq.  Because the =
UAS
might not have observed/remembered the prior request, I assume that the =
UAS
should not reject this request with a 400 response when the cseq becomes
between 2**31 and (2**32 - 1).

I think that situations like the above example, dialog recovery, =
etcetera
should be considered within the reasoning as to why it might not be wise =
for
a UAS to return a 400 response when it thinks that the cseq value
incorrectly started with a cseq between 2**31 and (2**32-1).

If re-submitting a request because of 401, 407, etcetera violates the
protocol, should RFC 3261 errata/bis be updated to enlighten the
implementers to leave a little cseq room for resubmissions to ensure =
that
the cseq 2**31 rule is not violated?



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Sat Dec 11 14:30:53 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12410
	for <sip-web-archive@ietf.org>; Sat, 11 Dec 2004 14:30:53 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdD4f-0000St-8O
	for sip-web-archive@ietf.org; Sat, 11 Dec 2004 14:38:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdCv9-00074m-Nx; Sat, 11 Dec 2004 14:28:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CdCth-0006k9-JV
	for sip@megatron.ietf.org; Sat, 11 Dec 2004 14:27:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12287
	for <sip@ietf.org>; Sat, 11 Dec 2004 14:27:15 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdD18-0000Oh-Oa for sip@ietf.org; Sat, 11 Dec 2004 14:35:00 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-3.cisco.com with ESMTP; 11 Dec 2004 12:32:43 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBBJQgPv005712;
	Sat, 11 Dec 2004 11:26:43 -0800 (PST)
Received: from [10.0.1.3] (sjc-vpn1-439.cisco.com [10.21.97.183])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUR49214;
	Sat, 11 Dec 2004 11:26:41 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Sat, 11 Dec 2004 04:52:32 -0800
From: Cullen Jennings <fluffy@cisco.com>
To: "sip@ietf.org" <sip@ietf.org>, Jonathan Rosenberg <jdrosen@cisco.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>,
        "gonzalo.camarillo@ericsson.com" <gonzalo.camarillo@ericsson.com>
Message-ID: <BDE02D90.1E294%fluffy@cisco.com>
In-Reply-To: <200411292017.PAA27162@ietf.org>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Subject: [Sip] question on draft-ietf-sip-sctp-05.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit


What do the following two lines look like if I am using TLS over SCTP?

      sip:Bob.Johnson@example.com;transport=sctp
      Via: SIP/2.0/SCTP ws1234.example.com:5060

And could you explicitly mention what the SRV lookups are like (particularly
with TLS and SCTP)

Thanks, Cullen


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Sat Dec 11 14:37:50 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12930
	for <sip-web-archive@ietf.org>; Sat, 11 Dec 2004 14:37:50 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdDBL-0000b5-BW
	for sip-web-archive@ietf.org; Sat, 11 Dec 2004 14:45:34 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdCvA-00074x-S2; Sat, 11 Dec 2004 14:28:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CdCti-0006kB-JS
	for sip@megatron.ietf.org; Sat, 11 Dec 2004 14:27:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12292
	for <sip@ietf.org>; Sat, 11 Dec 2004 14:27:16 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdD19-0000Oi-QB
	for sip@ietf.org; Sat, 11 Dec 2004 14:35:01 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-5.cisco.com with ESMTP; 11 Dec 2004 11:27:14 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBBJQe5M018816;
	Sat, 11 Dec 2004 11:26:41 -0800 (PST)
Received: from [10.0.1.3] (sjc-vpn1-439.cisco.com [10.21.97.183])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUR49215;
	Sat, 11 Dec 2004 11:26:42 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Sat, 11 Dec 2004 05:34:28 -0800
Subject: Re: [Sip] PING/PONG [bcc][faked-from][heur] [mx][spf]
From: Cullen Jennings <fluffy@cisco.com>
To: Christian Jansson <christian.jansson@hotsip.com>,
        Spencer Dawkins <spencer@mcsr-labs.org>,
        Christian Stredicke <Christian.Stredicke@snom.de>
Message-ID: <BDE03764.1E29A%fluffy@cisco.com>
In-Reply-To: <B7192C0D8D60754DADA9E22294C573696316D3@mailserver.hotsip.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.7 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit

On 11/12/04 4:00 AM, "Christian Jansson" <christian.jansson@hotsip.com>
wrote:

> I'm not sure how often keep-alives have to be sent over TCP to ensure
> that NAT/FWs do not remove the state. Preferabely NAT/FWs never remove
> the state, but I have heard that it happens. Does anyone have a
> reference to test statistics of NAT/FWs behavior? The keep-alive default
> interval should probably be set just below the shortest of all detected
> values.

Have not done extensive testing but on the ones I have tested, it has been
around 7200 seconds, and the default TCP keep alive in most OS is also 7200
seconds so they are matched and you can ignore it. I imagine they are not
all this way. The argument for TCP CRLF has been to detect the "liveness" of
the connection for reliably - not so much an argument for nat state refresh


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Sat Dec 11 15:56:50 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19801
	for <sip-web-archive@ietf.org>; Sat, 11 Dec 2004 15:56:50 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdEPr-0002Pf-J4
	for sip-web-archive@ietf.org; Sat, 11 Dec 2004 16:04:35 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdEGv-0006O6-0O; Sat, 11 Dec 2004 15:55:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CdEEf-0005Dt-MT
	for sip@megatron.ietf.org; Sat, 11 Dec 2004 15:53:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19626
	for <sip@ietf.org>; Sat, 11 Dec 2004 15:52:59 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CdEM8-0002Bf-Fl for sip@ietf.org; Sat, 11 Dec 2004 16:00:45 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 11 Dec 2004 13:58:27 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBBKqS5M002628;
	Sat, 11 Dec 2004 12:52:28 -0800 (PST)
Received: from [10.0.1.3] (sjc-vpn1-439.cisco.com [10.21.97.183])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUR50692;
	Sat, 11 Dec 2004 12:52:26 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Sat, 11 Dec 2004 12:52:33 -0800
Subject: Re: [Sip] target topology in connect-reuse
From: Cullen Jennings <fluffy@cisco.com>
To: Jonathan Rosenberg <jdrosen@cisco.com>, "sip@ietf.org" <sip@ietf.org>,
        Rohan Mahy <rohan@ekabal.com>
Message-ID: <BDE09E11.1F377%fluffy@cisco.com>
In-Reply-To: <419A5E86.7030009@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Content-Transfer-Encoding: 7bit
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Content-Transfer-Encoding: 7bit


I think the basic idea you are getting at here is right but not sure the TLS
part at the end is the right way to go. We might be saying the same thing.
I will try to explain.

I agree that the connection reuse checking needs to happen *after* the DNS
for a particular transaction. And because of this, a proxy on the left doing
lots of transaction to the right will end up with a connections to all the
proxies on the right.

The problem with the TLS is that a given proxy farm (say the one on the
right) may host several virtual domains. Say it is widgets.org and acme.org.
Now when the left side sends to acme.org, it needs to do the DNS, then look
in the connection cache for a connection to the resolved IP/port, then out
of all the connection to that destination look and see if one is a TLS
connection connected to acme.org. In this example each proxy on the left
could end up with two TLS connections (one for each virtual domain) to each
thing on the right. You can't just use the IP address as the index for the
alias for TLS. 

This is pretty easy to implement in most proxies doing TLS because, after
the DNS resolution is done, you still pass the domain name, along with the
IP address, down to the layer where the transport connection is formed so
that you can check that subjectAltName of the connection is correct.

The final thing has to do with this DNS dialback scheme for TLS - I think it
is, well, useless. Let's say DNS with no security claims that example.com
can resolve to 1.1.1.1 but TLS is connected to a host 2.2.2.2 which has
proven it has the private key for exmaple.com. Which one are you going to
believe? The TLS is a much stronger assertion. Ignoring the what do you
believe, you still don't need to do this dialback check if you do what is
described above because when someone goes to send a request, it will never
resolve the IP to this connection.



On 11/16/04 12:09 PM, "Jonathan Rosenberg" <jdrosen@cisco.com> wrote:

> During the sip meeting, we had a lot of discussion about the
> interactions between connect-reuse and the RFC 3263 mechanisms for load
> balancing. The current mechanism in connect-reuse will, I believe,
> create a single connection between a proxy in one domain and one of the
> servers in another domain.
> 
> I think the objective of the connect-reuse mechanism is to produce a
> topology that looks like this:
> 
>      Please view in a fixed-width font such as
>                      Courier.
> 
> 
> 
> 
> 
> 
>         +---------+
>         |         |
>         |         |
>         | Proxy   | ---
>         |         |    ------          +---------+
>         |         |\         -----     |         |
>         +---------+ \\            ---  |         |
>                       \                | Proxy   |
>                        \            -- |         |
>                         \\      ----   |         |
>         +---------+       \  ---     / +---------+
>         |         |       -\\       /
>         |         |   ----   \    //
>         | Proxy   | --        \  /
>         |         |            \X
>         |         | --         / \
>         +---------+   ----    /   \
>                           ---/     \\  +---------+
>                            / ----    \ |         |
>                           /      --    |         |
>                          /         --  | Proxy   |
>         +---------+     /       ---    |         |
>         |         |   //    ----       |         |
>         |         |  /   ---           +---------+
>         | Proxy   | / ---
>         |         | --
>         |         |
>         +---------+
> 
> That is, between each proxy in domain A and each proxy in domain B,
> there is a single connection used for traffic in each direction. The
> transaction load is distributed across those connections proportiaonlly
> to the weight factors in the SRV records.
> 
> This effect can be achieved if a connection is aliased to to an IP
> address, so that the connection reuse takes place *after* the DNS
> operations have occurred.
> 
> This means that, when one proxy (A) opens a connection to another (B), A
> has to tell B that, when B wants to send requests to a particular IP
> address, it can use this connection instead. This needs to be done
> securely.
> 
> I'd suggest the following. A opens a TCP connection to a server in B
> (based on the DNS lookup of B's domain). There is a TLS exhcange. A
> indicates to B an IP address for which it is an alias. B takes the
> domain from the subjectAltName in the cert presented by A, looks up the
> domain in DNS, and verifies that the offered IP address is listed in the
> DNS record. If so, it is accepted as an alias.
> 
> -Jonathan R.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec 13 08:02:07 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02251
	for <sip-web-archive@ietf.org>; Mon, 13 Dec 2004 08:02:07 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cdpxs-0004fO-Om
	for sip-web-archive@ietf.org; Mon, 13 Dec 2004 08:10:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CdpjL-0005md-N6; Mon, 13 Dec 2004 07:55:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CdpcS-0004Qa-28
	for sip@megatron.ietf.org; Mon, 13 Dec 2004 07:48:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01182
	for <sip@ietf.org>; Mon, 13 Dec 2004 07:48:03 -0500 (EST)
Received: from sierra.rtfm.com ([198.144.203.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdpkF-0004FU-Vn
	for sip@ietf.org; Mon, 13 Dec 2004 07:56:08 -0500
Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242])
	by sierra.rtfm.com (Postfix) with ESMTP
	id D1DA27241; Mon, 13 Dec 2004 05:09:34 -0800 (PST)
Received: by romeo.rtfm.com (Postfix, from userid 556)
	id AC60744ACF; Mon, 13 Dec 2004 04:47:27 -0800 (PST)
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] target topology in connect-reuse
References: <BDE09E11.1F377%fluffy@cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 13 Dec 2004 04:47:27 -0800
In-Reply-To: <BDE09E11.1F377%fluffy@cisco.com> (Cullen Jennings's message of
	"Sat, 11 Dec 2004 12:52:33 -0800")
Message-ID: <kjzn0i4b6o.fsf@romeo.rtfm.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
	Obscurity, berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: "sip@ietf.org" <sip@ietf.org>, Rohan Mahy <rohan@ekabal.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@rtfm.com>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465

Cullen Jennings <fluffy@cisco.com> writes:

> I think the basic idea you are getting at here is right but not sure the TLS
> part at the end is the right way to go. We might be saying the same thing.
> I will try to explain.
>
> I agree that the connection reuse checking needs to happen *after* the DNS
> for a particular transaction. And because of this, a proxy on the left doing
> lots of transaction to the right will end up with a connections to all the
> proxies on the right.
>
> The problem with the TLS is that a given proxy farm (say the one on the
> right) may host several virtual domains. Say it is widgets.org and acme.org.
> Now when the left side sends to acme.org, it needs to do the DNS, then look
> in the connection cache for a connection to the resolved IP/port, then out
> of all the connection to that destination look and see if one is a TLS
> connection connected to acme.org. In this example each proxy on the left
> could end up with two TLS connections (one for each virtual domain) to each
> thing on the right. You can't just use the IP address as the index for the
> alias for TLS. 
>
> This is pretty easy to implement in most proxies doing TLS because, after
> the DNS resolution is done, you still pass the domain name, along with the
> IP address, down to the layer where the transport connection is formed so
> that you can check that subjectAltName of the connection is correct.
It's worth noting that this only works correctly if either:

1. The TLS server has a wildcard or multi-name certificate.
2. You're using the server_name extension from RFC 3546. 

Otherwise you can't use name-based virtual hosts with TLS.

> The final thing has to do with this DNS dialback scheme for TLS - I think it
> is, well, useless. Let's say DNS with no security claims that example.com
> can resolve to 1.1.1.1 but TLS is connected to a host 2.2.2.2 which has
> proven it has the private key for exmaple.com. Which one are you going to
> believe? The TLS is a much stronger assertion. Ignoring the what do you
> believe, you still don't need to do this dialback check if you do what is
> described above because when someone goes to send a request, it will never
> resolve the IP to this connection.

This sounds correct to me.

-Ekr

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec 14 04:04:56 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03006
	for <sip-web-archive@ietf.org>; Tue, 14 Dec 2004 04:04:56 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ce8k5-0001pd-DD
	for sip-web-archive@ietf.org; Tue, 14 Dec 2004 04:13:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ce8aq-00067T-Sw; Tue, 14 Dec 2004 04:03:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce8XY-0005RF-GC
	for sip@megatron.ietf.org; Tue, 14 Dec 2004 04:00:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02817
	for <sip@ietf.org>; Tue, 14 Dec 2004 04:00:15 -0500 (EST)
Received: from mgw1.alpha.co.jp ([210.250.201.67])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce8fU-0001k5-G9
	for sip@ietf.org; Tue, 14 Dec 2004 04:08:31 -0500
Received: from mgw1.alpha.co.jp (localhost [127.0.0.1])
	by check_out.mgw1.alpha.co.jp (Postfix) with ESMTP id EAE244E612
	for <sip@ietf.org>; Tue, 14 Dec 2004 18:00:05 +0900 (JST)
Received: from sps-0004.alpha.co.jp (sps-0004.alpha.co.jp [10.128.240.2])
	by init.mgw1.alpha.co.jp (Postfix) with SMTP id AB966105403
	for <sip@ietf.org>; Tue, 14 Dec 2004 18:00:05 +0900 (JST)
Date: Tue, 14 Dec 2004 18:00:03 +0900
From: =?ISO-2022-JP?B?GyRCNF0+ZSEhQCE6SBsoQg==?= <marugas@alpha.co.jp>
X-Mailer: EdMax Ver2.85.5F
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20041214090004.E8096ED2@ms3.alpha.co.jp>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Subject: [Sip] transaction layer
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit

Hi,
I need help clarifying an issue in the handling of 
transport failure for transaction layer.

RFC3261 section 17.1.4 says that

"The client transaction SHOULD inform the TU that a transport 
failure has occurred, and the client transaction SHOULD 
transition directly to the "Terminated" state.  The TU will 
handle the failover mechanisms described in [4]."

Furthermore section 17.1.1.2 says that 

"When in either the "Calling" or "Proceeding" states, reception 
of a response with status code from 300-699 MUST cause the 
client transaction to transition to "Completed".The client 
transaction MUST pass the received response up to the TU, and 
the client transaction MUST generate an ACK request, even if the 
transport is reliable (guidelines for constructing the ACK from 
the response are given in Section 17.1.1.3) and then pass the 
ACK to the transport layer for transmission."

If the ACK request failed in this case, the client transaction 
SHOULD inform the TU the transport failure.

section 8.1.3.1 says that

"In some cases, the response returned by the transaction layer 
will   not be a SIP message, but rather a transaction layer 
error.  When a   timeout error is received from the transaction 
layer, it MUST be   treated as if a 408 (Request Timeout) status 
code has been received.   If a fatal transport error is reported 
by the transport layer   (generally, due to fatal ICMP errors in 
UDP or connection failures in   TCP), the condition MUST be 
treated as a 503 (Service Unavailable)   status code."

In this case, the TU must be treated as a 503 status code that 
it is based on section 8.1.3.1. But TU has already received 
300-699 response. Then, what should the TU do?

Thank you for your consideration.

-------------------
Marugami Sumiya
Alpha Systems, Inc.
-------------------


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec 14 04:19:22 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04069
	for <sip-web-archive@ietf.org>; Tue, 14 Dec 2004 04:19:21 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ce8y1-00029k-Ke
	for sip-web-archive@ietf.org; Tue, 14 Dec 2004 04:27:39 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ce8oL-0007qi-48; Tue, 14 Dec 2004 04:17:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CZLvd-0006M9-2e
	for sip@megatron.ietf.org; Tue, 30 Nov 2004 23:17:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24021
	for <sip@ietf.org>; Tue, 30 Nov 2004 23:17:18 -0500 (EST)
Received: from midce244.us.info.net ([63.250.163.244] helo=mailus.huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZM0r-0004qZ-FT
	for sip@ietf.org; Tue, 30 Nov 2004 23:22:46 -0500
Received: from mailus (mailus [172.18.4.2])
	by mailus.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built
	Mar 3 2004)) with ESMTP id <0I80003JEZDXD6@mailus.huawei.com> for
	sip@ietf.org; Tue, 30 Nov 2004 20:05:58 -0800 (PST)
Received: from huawei.com ([172.17.1.218])
	by mailus.huawei.com (iPlanet	Messaging Server 5.2 HotFix 0.8 (built
	Jul 122002)) with ESMTP id	<0I800019EZDVOE@mailus.huawei.com> for
	sip@ietf.org; Tue, 30 Nov 2004 20:05:57 -0800 (PST)
Received: from [172.24.1.3] (Forwarded-For: [10.70.104.115])
	by	szxmc02-in.huawei.com (mshttpd); Wed, 01 Dec 2004 12:16:47 +0800
Date: Wed, 01 Dec 2004 12:16:47 +0800
From: OmPrakashTripathi 70630 <omprakasht@huawei.com>
Subject: Re: [Sip-implementors] [Sip] OPTIONS outside dialog
To: Anil Bollineni <ABollineni@juniper.net>
Message-id: <9ac7b98c44.98c449ac7b@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: multipart/mixed; boundary="Boundary_(ID_HmP0R1IBBzKRxutRLsQb2w)"
Content-language: en
X-Accept-Language: en
Priority: normal
X-imss-version: 2.007
X-imss-result: Passed
X-imss-approveListMatch: *@huawei.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
X-Mailman-Approved-At: Tue, 14 Dec 2004 04:17:31 -0500
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81

This is a multi-part message in MIME format.

--Boundary_(ID_HmP0R1IBBzKRxutRLsQb2w)
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
Content-Transfer-Encoding: 7BIT

Hi,

   200 OK is the standard Response which one can expect or can send for any Out Of Dialog OPTIONS.
    In most of the cases devices cant understand the OPTIONS then its up to the Entity which sends the OPTIONS to decide what to accept.


Om..

----- Original Message -----
From: Anil Bollineni <ABollineni@juniper.net>
Date: Wednesday, December 1, 2004 7:09 am
Subject: [Sip-implementors] [Sip] OPTIONS outside dialog

> Hi,
> 
>    Assume OPTIONS comes outside dialog, what are the possible 
> responsesthat are for OPTIONS, assume these are the same responses 
> for any
> request as defined in RFC 3261. Please clarify.
> 
> 
> 
> Thanks in advance,
> 
> Anil
> 
> 
> 
> 

--Boundary_(ID_HmP0R1IBBzKRxutRLsQb2w)
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
Content-Transfer-Encoding: 7BIT

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

--Boundary_(ID_HmP0R1IBBzKRxutRLsQb2w)
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
Content-Transfer-Encoding: 7BIT

_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

--Boundary_(ID_HmP0R1IBBzKRxutRLsQb2w)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--Boundary_(ID_HmP0R1IBBzKRxutRLsQb2w)--



From sip-bounces@ietf.org  Tue Dec 14 04:23:48 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05656
	for <sip-web-archive@ietf.org>; Tue, 14 Dec 2004 04:23:48 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ce92K-0002N9-41
	for sip-web-archive@ietf.org; Tue, 14 Dec 2004 04:32:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ce8oM-0007qs-QP; Tue, 14 Dec 2004 04:17:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CZCHo-0006He-KN; Tue, 30 Nov 2004 12:59:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14401;
	Tue, 30 Nov 2004 12:59:33 -0500 (EST)
Received: from mtassp3.ncr.disa.mil ([164.117.82.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CZCMy-0002Bo-7W; Tue, 30 Nov 2004 13:04:56 -0500
Received: from mtassp3.ncr.disa.mil by mtassp3.ncr.disa.mil
	via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP;
	Tue, 30 Nov 2004 12:56:44 -0500
Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2657.72)
	id <XQ2MP2GS>; Tue, 30 Nov 2004 12:57:32 -0500
Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D0765166C@emshqs1.ncr.disa.mil>
From: "Nguyen, An" <An.Nguyen@ncs.gov>
To: "'Tom Taylor'" <taylor@nortelnetworks.com>
Date: Tue, 30 Nov 2004 12:59:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
X-Mailman-Approved-At: Tue, 14 Dec 2004 04:17:31 -0500
Cc: iptel@ietf.org, sip@ietf.org, "Jesske, R" <R.Jesske@t-com.net>
Subject: [Sip] RE: [Iptel] Calling Party's Category
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17

Mr. Taylor;

I am just curious ... What is the status of the Internet Draft?

An



-----Original Message-----
From: Tom Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, November 30, 2004 10:07 AM
To: Jesske, R
Cc: iptel@ietf.org; sip@ietf.org
Subject: Re: [Iptel] Calling Party's Category


The question was what the requirement is for this sort of indication.  How
is it used?

Jesske, R wrote:
> Dear all,
> in the past there was a discussion regarding the specification of a
Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt)
> What is the actual status of this activity. 
> We are still interested in such kind of originating indication if the
call/communication is coming from a normal SIP user or a SIP -Payphone or
SIP-Hotelphone. 
> Is there a interest from other parties in this issue?
> 
> Best Regards
> 
> Roland
> 
> Deutsche Telekom AG
> T-Com Zentrale
> Roland Jesske, TE332-2
> Section TE33; Signalling, Gateways and Switching Systems 
> Am Kavalleriesand 3, 64295 Darmstadt, Germany
> Phone:  +49 6151 83-5940 
> Fax:      +49 6151 83-4577 
> email:   r.jesske@t-com.net
> 
> 
> 
> 
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www1.ietf.org/mailman/listinfo/iptel
> 
> 

-- 
Tom Taylor
Carrier VoIP Standards Development
Nortel Networks
Phone +1 613 763 1496  (ESN 393-1496)
E-mail: taylor@nortelnetworks.com

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www1.ietf.org/mailman/listinfo/iptel



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec 14 07:31:05 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19613
	for <sip-web-archive@ietf.org>; Tue, 14 Dec 2004 07:31:05 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeBxb-0006mQ-0d
	for sip-web-archive@ietf.org; Tue, 14 Dec 2004 07:39:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeBmX-0004Tw-TU; Tue, 14 Dec 2004 07:27:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeBlz-0004J2-4v
	for sip@megatron.ietf.org; Tue, 14 Dec 2004 07:27:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19156
	for <sip@ietf.org>; Tue, 14 Dec 2004 07:27:22 -0500 (EST)
Received: from ip-207-145-48-18.sjc.megapath.net ([207.145.48.18])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CeBtz-0006c2-PW
	for sip@ietf.org; Tue, 14 Dec 2004 07:35:40 -0500
Received: from brahma.intotoind.com ([66.80.10.146])
	by ip-207-145-48-18.sjc.megapath.net (SMSSMTP 4.0.0.59) with SMTP id
	M2004121404262619740
	for <sip@ietf.org>; Tue, 14 Dec 2004 04:26:26 -0800
Received: from surya.intoto.com (2mc100.intotoind.com [172.16.2.100])
	by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id iBECQeGY008493
	for <sip@ietf.org>; Tue, 14 Dec 2004 17:56:41 +0530
Message-Id: <6.1.2.0.0.20041214141540.02433e10@172.16.1.10>
X-Sender: asurya@172.16.1.10
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Tue, 14 Dec 2004 17:58:17 +0530
To: sip@ietf.org
From: Surya Santosh <asurya@intoto.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.41
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Subject: [Sip] Sending 200 OK after receiving ACK
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

Hi All,

I have a doubt regarding the processing of ACK  by the UA. The UA , even 
after receving ACK from the other UA is still sending 200 OK's.

I am using the following configuration.

Host1------------Firewall---------------------------Internet
                                          |
                                          |
                                        Host2

I am using AOL instant messenger on both the hosts. I started video from 
Host2 to Host1. As AOL video uses SIP for connection establishment, Host1 
sends SIP INVITE to HOST2 and the following figure depicts the flow of the 
packets between the two UA's.

Host1--------------------------------------Host2
INVITE---------------------->
           <---------------------  100 Trying
           <---------------------  180 Ringing
           <---------------------- 200 OK
ACK    ----------------------->

After receiving the ACK, Host 2 is still sending 200 OK's . It is happening 
often but not all the times.
I have attached the capture of both success case and failure case. Could 
anyone please help me in finding out why Host2 is sending 200 OK' s even 
after receiving ACK.












_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec 14 10:26:42 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08813
	for <sip-web-archive@ietf.org>; Tue, 14 Dec 2004 10:26:42 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeEhZ-0004Hy-Hl
	for sip-web-archive@ietf.org; Tue, 14 Dec 2004 10:35:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeERn-0000vM-G5; Tue, 14 Dec 2004 10:18:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeECZ-0002Fj-7X
	for sip@megatron.ietf.org; Tue, 14 Dec 2004 10:02:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05016
	for <sip@ietf.org>; Tue, 14 Dec 2004 10:02:57 -0500 (EST)
Received: from motgate8.mot.com ([129.188.136.8])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeEKZ-0003YG-Qi
	for sip@ietf.org; Tue, 14 Dec 2004 10:11:17 -0500
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132])
	by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iBEF4bfL006229
	for <sip@ietf.org>; Tue, 14 Dec 2004 08:04:37 -0700 (MST)
Received: from zes06exm01.madrid.ecid.cig.mot.com ([10.161.1.12])
	by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id iBEF1Z96009308
	for <sip@ietf.org>; Tue, 14 Dec 2004 09:01:36 -0600
Received: by zes06exm01.madrid.ecid.cig.mot.com with Internet Mail Service
	(5.5.2657.72) id <4QKCZWDR>; Tue, 14 Dec 2004 16:02:52 +0100
Message-ID: <C688FD61564849429C7165340EFF99B504A4A989@zes06exm01.madrid.ecid.cig.mot.com>
From: Andonegui Jesus-JANDONE1 <jesus.andonegui@motorola.com>
To: sip@ietf.org
Date: Tue, 14 Dec 2004 16:02:44 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Spam-Score: 2.6 (++)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Subject: [Sip] Provisional response for re-INVITE
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0647821300=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 2.6 (++)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0647821300==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4E1ED.F7445B8C"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4E1ED.F7445B8C
Content-Type: text/plain

Hi all,
 
I have a question regarding following scenario: my server is acting as a proxy that does record-route, ie it wants to be kept in the path for future requests. When the proxy receives a re-INVITE, it will pass the re-INVITE to the other end. The question is, if the proxy is allowed to send a provisional response to the transmitter of the re-INVITE in order to stop the retransmission of the re-INVITE and also to avoid that the transmitter of the re-INVITE drops the call if it takes too long for the other end to send the 200 response to the re-INVITE. 
 
Thanks,
Jesus

------_=_NextPart_001_01C4E1ED.F7445B8C
Content-Type: text/html
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF
Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S
PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4NCjxESVY+PEZP
TlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9MjQ3MjMzMTE0LTE0MTIyMDA0PkhpIA0K
YWxsLDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxT
UEFOIA0KY2xhc3M9MjQ3MjMzMTE0LTE0MTIyMDA0PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+
DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTI0NzIzMzExNC0xNDEy
MjAwND5JIGhhdmUgYSBxdWVzdGlvbiANCnJlZ2FyZGluZyBmb2xsb3dpbmcgc2NlbmFyaW86IG15
IHNlcnZlciBpcyBhY3RpbmcgYXMgYSBwcm94eSB0aGF0IGRvZXMgDQpyZWNvcmQtcm91dGUsIGll
IGl0IHdhbnRzIHRvIGJlIGtlcHQgaW4gdGhlIHBhdGggZm9yIGZ1dHVyZSByZXF1ZXN0cy4gV2hl
biB0aGUgDQpwcm94eSByZWNlaXZlcyBhIHJlLUlOVklURSwgaXQgd2lsbCBwYXNzIHRoZSByZS1J
TlZJVEUgdG8gdGhlIG90aGVyIGVuZC4gVGhlIA0KcXVlc3Rpb24gaXMsIGlmIHRoZSBwcm94eSBp
cyBhbGxvd2VkIHRvIHNlbmQgYSBwcm92aXNpb25hbCByZXNwb25zZSB0byB0aGUgDQp0cmFuc21p
dHRlciBvZiB0aGUgcmUtSU5WSVRFIGluIG9yZGVyIHRvIHN0b3AgdGhlIHJldHJhbnNtaXNzaW9u
IG9mIHRoZSANCnJlLUlOVklURSBhbmQgYWxzbyB0byBhdm9pZCB0aGF0IHRoZSB0cmFuc21pdHRl
ciBvZiB0aGUgcmUtSU5WSVRFIGRyb3BzIHRoZSBjYWxsIA0KaWYgaXQgdGFrZXMgdG9vIGxvbmcg
Zm9yIHRoZSBvdGhlciBlbmQgdG8gc2VuZCB0aGUgMjAwIHJlc3BvbnNlIHRvIHRoZSANCnJlLUlO
VklURS4gPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+
PFNQQU4gY2xhc3M9MjQ3MjMzMTE0LTE0MTIyMDA0PjwvU1BBTj48L0ZPTlQ+PEZPTlQgDQpmYWNl
PUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0yNDcyMzMxMTQtMTQxMjIwMDQ+PC9TUEFOPjwvRk9O
VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFz
cz0yNDcyMzMxMTQtMTQxMjIwMDQ+VGhhbmtzLDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG
T05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MjQ3MjMzMTE0LTE0MTIyMDA0Pkpl
c3VzPC9TUEFOPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

------_=_NextPart_001_01C4E1ED.F7445B8C--


--===============0647821300==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0647821300==--



From sip-bounces@ietf.org  Tue Dec 14 21:01:57 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14575
	for <sip-web-archive@ietf.org>; Tue, 14 Dec 2004 21:01:57 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeOcR-0005us-8H
	for sip-web-archive@ietf.org; Tue, 14 Dec 2004 21:10:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeORP-0005J6-9u; Tue, 14 Dec 2004 20:58:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeONL-0004rE-Qu
	for sip@megatron.ietf.org; Tue, 14 Dec 2004 20:54:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14049
	for <sip@ietf.org>; Tue, 14 Dec 2004 20:54:46 -0500 (EST)
Received: from borg.juniper.net ([207.17.137.119])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeOVT-0005jZ-Ul
	for sip@ietf.org; Tue, 14 Dec 2004 21:03:12 -0500
Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126)
	by borg.juniper.net with ESMTP; 14 Dec 2004 17:54:15 -0800
X-BrightmailFiltered: true
X-Ironport-AV: i="3.87,143,1099296000"; 
	d="scan'208"; a="62366512:sNHT20939436"
Received: from hadron.jnpr.net ([172.24.15.25]) by alpha.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Dec 2004 17:54:15 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Sending 200 OK after receiving ACK
Date: Tue, 14 Dec 2004 17:54:15 -0800
Message-ID: <F07F17B61B7FF545BC7D7E4BFBE15D2A474022@hadron.jnpr.net>
Thread-Topic: [Sip] Sending 200 OK after receiving ACK
Thread-Index: AcTh2MmuSSdoDHwGRO+dea5I11G23gAb4hYg
From: "Anil Bollineni" <ABollineni@juniper.net>
To: "Surya Santosh" <asurya@intoto.com>, <sip@ietf.org>
X-OriginalArrivalTime: 15 Dec 2004 01:54:15.0965 (UTC)
	FILETIME=[FB95FCD0:01C4E248]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: quoted-printable
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Content-Transfer-Encoding: quoted-printable

Santosh,
   It can be because of some reasons, based on my experience,
	i. Check if the ACK packet is passed through firewall.
	ii. Check the ACK packet contents whether it match the INVITE
transaction.
	iii. It could be a problem with AOL messenger, with 200 Ok
retransmission algorithm :).

Hope it helps,
Anil

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Surya Santosh
Sent: Tuesday, December 14, 2004 4:28 AM
To: sip@ietf.org
Subject: [Sip] Sending 200 OK after receiving ACK

Hi All,

I have a doubt regarding the processing of ACK  by the UA. The UA , even

after receving ACK from the other UA is still sending 200 OK's.

I am using the following configuration.

Host1------------Firewall---------------------------Internet
                                          |
                                          |
                                        Host2

I am using AOL instant messenger on both the hosts. I started video from

Host2 to Host1. As AOL video uses SIP for connection establishment,
Host1=20
sends SIP INVITE to HOST2 and the following figure depicts the flow of
the=20
packets between the two UA's.

Host1--------------------------------------Host2
INVITE---------------------->
           <---------------------  100 Trying
           <---------------------  180 Ringing
           <---------------------- 200 OK
ACK    ----------------------->

After receiving the ACK, Host 2 is still sending 200 OK's . It is
happening=20
often but not all the times.
I have attached the capture of both success case and failure case. Could

anyone please help me in finding out why Host2 is sending 200 OK' s even

after receiving ACK.












_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec 14 22:56:56 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23644
	for <sip-web-archive@ietf.org>; Tue, 14 Dec 2004 22:56:56 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeQPk-00006G-7m
	for sip-web-archive@ietf.org; Tue, 14 Dec 2004 23:05:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeQFT-0005R7-Ev; Tue, 14 Dec 2004 22:54:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeQEz-0005KS-Qz
	for sip@megatron.ietf.org; Tue, 14 Dec 2004 22:54:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23405
	for <sip@ietf.org>; Tue, 14 Dec 2004 22:54:15 -0500 (EST)
Received: from rwcrmhc12.comcast.net ([216.148.227.85])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeQN9-0008Se-0H
	for sip@ietf.org; Tue, 14 Dec 2004 23:02:43 -0500
Received: from dfnjgl21 (c-24-1-97-29.client.comcast.net[24.1.97.29])
	by comcast.net (rwcrmhc12) with SMTP
	id <2004121503534101400ecqmbe>; Wed, 15 Dec 2004 03:53:41 +0000
Message-ID: <3b8301c4e259$dc1273a0$90878182@DFNJGL21>
From: "Spencer Dawkins" <spencer@mcsr-labs.org>
To: <sip@ietf.org>
References: <F07F17B61B7FF545BC7D7E4BFBE15D2A474022@hadron.jnpr.net>
Subject: Re: [Sip] Sending 200 OK after receiving ACK
Date: Tue, 14 Dec 2004 21:55:03 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Spencer Dawkins <spencer@mcsr-labs.org>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit

My apologies for a possibly non-profound question, but

- where are you monitoring the exchange?

If you're sitting on top of Host1, just because you saw the ACK go 
past, doesn't mean Host2 has seen it yet.

If you're sitting on top of Host2, which is still misbehaving, 
something else must be going on, but I had to ask...

Thanks,

Spencer

-------------------------------------------------------

Host1--------------------------------------Host2
INVITE---------------------->
           <---------------------  100 Trying
           <---------------------  180 Ringing
           <---------------------- 200 OK
ACK    ----------------------->

After receiving the ACK, Host 2 is still sending 200 OK's . It is
happening
often but not all the times.
I have attached the capture of both success case and failure case. 
Could

anyone please help me in finding out why Host2 is sending 200 OK' s 
even

after receiving ACK. 



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec 15 02:31:39 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02649
	for <sip-web-archive@ietf.org>; Wed, 15 Dec 2004 02:31:39 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeTlY-00059R-Au
	for sip-web-archive@ietf.org; Wed, 15 Dec 2004 02:40:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeTRt-0003b1-MD; Wed, 15 Dec 2004 02:19:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeTRJ-0003Nr-UZ; Wed, 15 Dec 2004 02:19:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22620;
	Wed, 15 Dec 2004 02:19:11 -0500 (EST)
Received: from mail4.telekom.de ([195.243.210.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeTZU-0004sq-6w; Wed, 15 Dec 2004 02:27:40 -0500
Received: from g8pbq.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP;
	Wed, 15 Dec 2004 08:18:21 +0100
Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <YZK80HG5>; Wed, 15 Dec 2004 08:18:37 +0100
Message-Id: <E7666D92C64C2845AEF12636FF94F952F97598@S4DE8PSAAGQ.blf.telekom.de>
From: "Jesske, R" <R.Jesske@t-com.net>
To: An.Nguyen@ncs.gov, taylor@nortelnetworks.com
Subject: AW: [Sip] RE: [Iptel] Calling Party's Category
Date: Wed, 15 Dec 2004 08:18:36 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Content-Transfer-Encoding: quoted-printable
Cc: iptel@ietf.org, sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Content-Transfer-Encoding: quoted-printable

Hello An
The below mentioned draft is expiered. There is no work in SIP or IPTEL =
at the moment, but we hope it will.
We brought up the issue, becuse we see the demand on such a element in =
SIP.

Best Regerds

Roland

> -----Urspr=FCngliche Nachricht-----
> Von: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]Im Auftrag von
> Nguyen, An
> Gesendet: Dienstag, 30. November 2004 19:00
> An: 'Tom Taylor'
> Cc: iptel@ietf.org; sip@ietf.org; Jesske, Roland
> Betreff: [Sip] RE: [Iptel] Calling Party's Category
>=20
>=20
> Mr. Taylor;
>=20
> I am just curious ... What is the status of the Internet Draft?
>=20
> An
>=20
>=20
>=20
> -----Original Message-----
> From: Tom Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Tuesday, November 30, 2004 10:07 AM
> To: Jesske, R
> Cc: iptel@ietf.org; sip@ietf.org
> Subject: Re: [Iptel] Calling Party's Category
>=20
>=20
> The question was what the requirement is for this sort of=20
> indication.  How
> is it used?
>=20
> Jesske, R wrote:
> > Dear all,
> > in the past there was a discussion regarding the specification of a
> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt)
> > What is the actual status of this activity.=20
> > We are still interested in such kind of originating=20
> indication if the
> call/communication is coming from a normal SIP user or a SIP=20
> -Payphone or
> SIP-Hotelphone.=20
> > Is there a interest from other parties in this issue?
> >=20
> > Best Regards
> >=20
> > Roland
> >=20
> > Deutsche Telekom AG
> > T-Com Zentrale
> > Roland Jesske, TE332-2
> > Section TE33; Signalling, Gateways and Switching Systems=20
> > Am Kavalleriesand 3, 64295 Darmstadt, Germany
> > Phone:  +49 6151 83-5940=20
> > Fax:      +49 6151 83-4577=20
> > email:   r.jesske@t-com.net
> >=20
> >=20
> >=20
> >=20
> > _______________________________________________
> > Iptel mailing list
> > Iptel@ietf.org
> > https://www1.ietf.org/mailman/listinfo/iptel
> >=20
> >=20
>=20
> --=20
> Tom Taylor
> Carrier VoIP Standards Development
> Nortel Networks
> Phone +1 613 763 1496  (ESN 393-1496)
> E-mail: taylor@nortelnetworks.com
>=20
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www1.ietf.org/mailman/listinfo/iptel
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec 15 04:37:05 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15514
	for <sip-web-archive@ietf.org>; Wed, 15 Dec 2004 04:37:05 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeViy-0008Ti-EE
	for sip-web-archive@ietf.org; Wed, 15 Dec 2004 04:45:36 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeVRR-0003bZ-4b; Wed, 15 Dec 2004 04:27:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeVNd-0002Sh-L9
	for sip@megatron.ietf.org; Wed, 15 Dec 2004 04:23:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14430
	for <sip@ietf.org>; Wed, 15 Dec 2004 04:23:31 -0500 (EST)
Received: from mgw1.alpha.co.jp ([210.250.201.67])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeVVp-00086h-IE
	for sip@ietf.org; Wed, 15 Dec 2004 04:32:02 -0500
Received: from mgw1.alpha.co.jp (localhost [127.0.0.1])
	by check_out.mgw1.alpha.co.jp (Postfix) with ESMTP id 78ACF4E611
	for <sip@ietf.org>; Wed, 15 Dec 2004 18:23:15 +0900 (JST)
Received: from sps-0004.alpha.co.jp (sps-0004.alpha.co.jp [10.128.240.2])
	by init.mgw1.alpha.co.jp (Postfix) with SMTP id 53AEE105403
	for <sip@ietf.org>; Wed, 15 Dec 2004 18:23:15 +0900 (JST)
Date: Wed, 15 Dec 2004 18:22:01 +0900
From: Norihiko Tashi <tashin@alpha.co.jp>
To: sip@ietf.org
Message-Id: <20041215162145.765B.TASHIN@alpha.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.10.04 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit
Subject: [Sip] Questions about early dialog
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit

Hi,

I have questions about an INVITE "early" dialog.

Question 1.
In an INVITE early dialog, can UA send or process other dialog-
creating methods(e.g. SUBSCRIBE)?

If so, SUBSCRIBE messages in the mid-dialog can establish subscriptions.

In this case, if the first INVITE (dialog-creating) transaction
terminated later (e.g. non-2xx final response, transport error 
or timeout) , should the dialog terminate despite existence of 
subscriptions?


Question 2.

A UAS can inform methods that that can be used in the dialog while this is
in the early state as below (RFC3261 13.2.2.1).

How does a UAC inform methods that can be used 
in "only" the early dialog?

Is only solution UAS's reception of a response 
with "405 Method Not Allowed"?


> 13.2.2.1 1xx Responses
>    The early dialog will only be needed if the UAC needs to send a
>    request to its peer within the dialog before the initial INVITE
>    transaction completes.  Header fields present in a provisional
>    response are applicable as long as the dialog is in the early state
>    (for example, an Allow header field in a provisional response
>    contains the methods that can be used in the dialog while this is in
>    the early state).


Thanks in advance.

---------------------
Norihiko Tashi
Alpha Systems, Inc.
---------------------





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec 15 07:14:56 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25266
	for <sip-web-archive@ietf.org>; Wed, 15 Dec 2004 07:14:56 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeYBl-0003jA-4E
	for sip-web-archive@ietf.org; Wed, 15 Dec 2004 07:23:29 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeXzf-0000eD-Bu; Wed, 15 Dec 2004 07:10:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeXxP-0008N2-LB
	for sip@megatron.ietf.org; Wed, 15 Dec 2004 07:08:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24652
	for <sip@ietf.org>; Wed, 15 Dec 2004 07:08:36 -0500 (EST)
Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeY5b-0003YR-CF
	for sip@ietf.org; Wed, 15 Dec 2004 07:17:09 -0500
Received: from Nataraju ([192.168.2.115])
	by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id
	iBFC78814992; Wed, 15 Dec 2004 17:37:15 +0530
From: "Nataraju A B" <bnataraju@kodiaknetworks.com>
To: "'Norihiko Tashi'" <tashin@alpha.co.jp>, <sip@ietf.org>
Subject: RE: [Sip] Questions about early dialog
Date: Wed, 15 Dec 2004 17:32:11 +0530
Message-ID: <005501c4e29d$ef605ff0$7302a8c0@Nataraju>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <20041215162145.765B.TASHIN@alpha.co.jp>
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: 7bit
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Content-Transfer-Encoding: 7bit



Best Regards,
Nataraju A.B.
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Norihiko Tashi
Sent: Wednesday, December 15, 2004 2:52 PM
To: sip@ietf.org
Subject: [Sip] Questions about early dialog

Hi,

I have questions about an INVITE "early" dialog.

Question 1.
In an INVITE early dialog, can UA send or process other dialog-
creating methods(e.g. SUBSCRIBE)?

If so, SUBSCRIBE messages in the mid-dialog can establish subscriptions.

In this case, if the first INVITE (dialog-creating) transaction
terminated later (e.g. non-2xx final response, transport error 
or timeout) , should the dialog terminate despite existence of 
subscriptions?

[ABN] there can be multiple dialogs in a session.... when you send the
subscribe within session then that creates one more dialog as part of
the same session....
when dialog created by INVITE is terminated then dialog created by
SUBSCRIBE still goes on... in this case only session exists with the
subscription dialog... 

Basically there can be multiple dialogs as part of the same session..
some thing similar to multiple transactions in a dialog...

Question 2.

A UAS can inform methods that that can be used in the dialog while this
is
in the early state as below (RFC3261 13.2.2.1).

How does a UAC inform methods that can be used 
in "only" the early dialog?

Is only solution UAS's reception of a response 
with "405 Method Not Allowed"?

[ABN] this may not be required... basic constraint is that, at any point
in time there can be overlap between INVITE and non-INVITE transactions
within a dialog. But there CAN'T be multiple INVITE transactions as part
of the same dialog...


> 13.2.2.1 1xx Responses
>    The early dialog will only be needed if the UAC needs to send a
>    request to its peer within the dialog before the initial INVITE
>    transaction completes.  Header fields present in a provisional
>    response are applicable as long as the dialog is in the early state
>    (for example, an Allow header field in a provisional response
>    contains the methods that can be used in the dialog while this is
in
>    the early state).

[ABN] this does mean that before INVITE transaction completes you can
send any request other than new INVITE request....

if you go through RFC3263 about Offer/Answer model you can understand
this topic pretty well...

Thanks in advance.

---------------------
Norihiko Tashi
Alpha Systems, Inc.
---------------------





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec 15 09:44:51 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04459
	for <sip-web-archive@ietf.org>; Wed, 15 Dec 2004 09:44:51 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CeaWV-0007Kk-LR
	for sip-web-archive@ietf.org; Wed, 15 Dec 2004 09:53:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CeaHl-0007L2-Bh; Wed, 15 Dec 2004 09:37:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cea8W-0005G0-0l
	for sip@megatron.ietf.org; Wed, 15 Dec 2004 09:28:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03458
	for <sip@ietf.org>; Wed, 15 Dec 2004 09:28:13 -0500 (EST)
Received: from smtp7.clb.oleane.net ([213.56.31.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeaGk-0006wo-Qw
	for sip@ietf.org; Wed, 15 Dec 2004 09:36:47 -0500
Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be
	forged)) by smtp7.clb.oleane.net with ESMTP id iBFERe3I017135
	for <sip@ietf.org>; Wed, 15 Dec 2004 15:27:43 +0100
Message-Id: <200412151427.iBFERe3I017135@smtp7.clb.oleane.net>
From: "Gunter" <g.palmer@dial.oleane.com>
To: <sip@ietf.org>
Date: Wed, 15 Dec 2004 15:27:42 +0100
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTisjx7TzzNiTBsRUCV5Ofg2km9ug==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 225414c974e0d6437992164e91287a51
Subject: [Sip] WiMAX Summit'05 - Paris - France
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0987884095=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c

This is a multi-part message in MIME format.

--===============0987884095==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_03E2_01C4E2BA.9E8E8030"

This is a multi-part message in MIME format.

------=_NextPart_000_03E2_01C4E2BA.9E8E8030
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

. What is the business model for WiMAX? 
. What do we learn from earlier deployments? 
. What about the future extensions of the standard? 
. How is addressed the interoperability challenge? 

These questions, among others, will be addressed during the second edition
of the WiMAX Summit to be organised in Paris next 5-8 April 2005.

 

Get all details at:

 <http://www.upperside.fr/wimax05/wimax2005intro.htm>
http://www.upperside.fr/wimax05/wimax2005intro.htm

 

 


------=_NextPart_000_03E2_01C4E2BA.9E8E8030
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"\@Batang";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><strong><b><font size=3D1 face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:9.0pt;font-family:Arial'>&#8226; =
</span></font></b></strong><font
size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial'>What
is the <strong><b><font face=3DArial><span =
style=3D'font-family:Arial'>business
model</span></font></b></strong> for WiMAX? <br>
<strong><b><font face=3DArial><span style=3D'font-family:Arial'>&#8226; =
</span></font></b></strong>What
do we learn from <strong><b><font face=3DArial><span =
style=3D'font-family:Arial'>earlier
deployments</span></font></b></strong>? <br>
<strong><b><font face=3DArial><span style=3D'font-family:Arial'>&#8226; =
</span></font></b></strong>What
about the <strong><b><font face=3DArial><span =
style=3D'font-family:Arial'>future
extensions</span></font></b></strong> of the standard? <br>
<strong><b><font face=3DArial><span style=3D'font-family:Arial'>&#8226; =
</span></font></b></strong>How
is addressed the <strong><b><font face=3DArial><span =
style=3D'font-family:Arial'>interoperability</span></font></b></strong>
challenge? <br>
<br>
These questions, among others, will be addressed during the second =
edition of
the WiMAX Summit to be organised in <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Paris</st1:City></st1:place>
next 5-8 April 2005.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
9.0pt;font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
9.0pt;font-family:Arial'>Get all details =
at:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 face=3DArial><span =
style=3D'font-size:9.0pt;
font-family:Arial'><a =
href=3D"http://www.upperside.fr/wimax05/wimax2005intro.htm"
title=3D"http://www.upperside.fr/wimax05/wimax2005intro.htm"><span =
lang=3DEN-GB><span
title=3D"http://www.upperside.fr/wimax05/wimax2005intro.htm">http://www.u=
pperside.fr/wimax05/wimax2005intro.htm</span></span></a></span></font><fo=
nt
size=3D1 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:9.0pt;font-family:Arial'><o:p></o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_03E2_01C4E2BA.9E8E8030--



--===============0987884095==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0987884095==--




From sip-bounces@ietf.org  Wed Dec 15 11:52:01 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16225
	for <sip-web-archive@ietf.org>; Wed, 15 Dec 2004 11:52:01 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CecVv-0002JK-Dy
	for sip-web-archive@ietf.org; Wed, 15 Dec 2004 12:00:36 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CecHr-0001oC-IV; Wed, 15 Dec 2004 11:46:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CecEa-0000sz-LN
	for sip@megatron.ietf.org; Wed, 15 Dec 2004 11:42:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15510
	for <sip@ietf.org>; Wed, 15 Dec 2004 11:42:37 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CecMq-00024C-HZ for sip@ietf.org; Wed, 15 Dec 2004 11:51:13 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-1.cisco.com with ESMTP; 15 Dec 2004 08:48:00 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBFGg0W2005732;
	Wed, 15 Dec 2004 08:42:04 -0800 (PST)
Received: from [10.32.131.131] ([10.32.131.131])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUT86173;
	Wed, 15 Dec 2004 08:42:01 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Wed, 15 Dec 2004 09:31:07 -0700
Subject: Re: [Sip] target topology in connect-reuse
From: Cullen Jennings <fluffy@cisco.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <BDE5B4DB.1F9CB%fluffy@cisco.com>
In-Reply-To: <kjzn0i4b6o.fsf@romeo.rtfm.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Rohan Mahy <rohan@ekabal.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit

On 12/13/04 4:47 AM, "Eric Rescorla" <ekr@rtfm.com> wrote:

> It's worth noting that this only works correctly if either:
> 
> 1. The TLS server has a wildcard or multi-name certificate.
> 2. You're using the server_name extension from RFC 3546.
> 
> Otherwise you can't use name-based virtual hosts with TLS.

Yes. I was assuming more 2 than 1 - we are trying to get this into SIP stuff
but I don't believe anyone has implemented it yet. I think the wildcards are
forbitten in sip but multi-name are allowed. I'm not sure if anyone will use
them.  



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec 15 12:59:45 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22843
	for <sip-web-archive@ietf.org>; Wed, 15 Dec 2004 12:59:45 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CedZU-0004kL-4L
	for sip-web-archive@ietf.org; Wed, 15 Dec 2004 13:08:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CedEy-0004ri-PK; Wed, 15 Dec 2004 12:47:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ced5H-0008Oz-DW
	for sip@megatron.ietf.org; Wed, 15 Dec 2004 12:37:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19591
	for <sip@ietf.org>; Wed, 15 Dec 2004 12:37:03 -0500 (EST)
Received: from wproxy.gmail.com ([64.233.184.197])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CedDW-0003XD-U5
	for sip@ietf.org; Wed, 15 Dec 2004 12:45:40 -0500
Received: by wproxy.gmail.com with SMTP id 37so1932387wra
	for <sip@ietf.org>; Wed, 15 Dec 2004 09:36:34 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
	b=sHOd1Ado9VE0MRZ3j33YHN8G08I0qshUezmM83j4Gb2ALP9LEZIgoYfST60+So8Q7VyNEeGdKtwbhlSd6hsuXbKt9mKGkIftohjLXsjUzXxIzzJc6kusLCN/BFBwuZrcUr4F8egkMRA9Zsp4KCf4XANbvzbXmZ5zmOmeKWnZ4mM=
Received: by 10.54.4.40 with SMTP id 40mr2148522wrd;
	Wed, 15 Dec 2004 09:36:34 -0800 (PST)
Received: by 10.54.45.16 with HTTP; Wed, 15 Dec 2004 09:36:34 -0800 (PST)
Message-ID: <373517a1041215093633906525@mail.gmail.com>
Date: Wed, 15 Dec 2004 12:36:34 -0500
From: Robert Sanders <rsanders@gmail.com>
To: sip@ietf.org
Subject: Re: [Sip] target topology in connect-reuse
In-Reply-To: <BDE5B4DB.1F9CB%fluffy@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <kjzn0i4b6o.fsf@romeo.rtfm.com> <BDE5B4DB.1F9CB%fluffy@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Robert Sanders <rsanders@gmail.com>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit

On Wed, 15 Dec 2004 09:31:07 -0700, Cullen Jennings <fluffy@cisco.com> wrote:

> Yes. I was assuming more 2 than 1 - we are trying to get this into SIP stuff
> but I don't believe anyone has implemented it yet. I think the wildcards are
> forbitten in sip but multi-name are allowed. I'm not sure if anyone will use
> them.

We have well over 300,000 hosted domains at EarthLink, and around 150
domains in our consumer service.  We absolutely must use the
server_name extension.  I can't imagine us doing TLS without it.  We
might *also* want multi-name, as we currently allow people to use URIs
of the form <user>@sip.<domain> as aliases for <name>@<domain>, where
sip.<domain> has an A record for the proxy for <domain>.  This is
primariy for working around proxies that don't support SRV.  But
multi-name is clearly neither necessary if there is mandatory support
for server_name, nor a sufficient replacement for it.

regards,
  -- Robert

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec 15 15:45:24 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08807
	for <sip-web-archive@ietf.org>; Wed, 15 Dec 2004 15:45:24 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ceg9o-0000uY-DT
	for sip-web-archive@ietf.org; Wed, 15 Dec 2004 15:54:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CefwK-0000BO-63; Wed, 15 Dec 2004 15:40:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CefoZ-0004EF-LY
	for sip@megatron.ietf.org; Wed, 15 Dec 2004 15:32:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07581
	for <sip@ietf.org>; Wed, 15 Dec 2004 15:32:01 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cefwp-0000cX-Jd
	for sip@ietf.org; Wed, 15 Dec 2004 15:40:38 -0500
Received: from [64.101.149.107] ([64.101.149.107]) (authenticated bits=0)
	by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iBFKWmh8017738
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 15 Dec 2004 14:32:49 -0600
In-Reply-To: <BDB17FCD.189BD%fluffy@cisco.com>
References: <BDB17FCD.189BD%fluffy@cisco.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <65013299-4ED8-11D9-86D7-000D93594350@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] refer-with-norefersub
Date: Wed, 15 Dec 2004 14:32:09 -0600
To: Cullen Jennings <fluffy@cisco.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Orit Levin <oritl@microsoft.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit


Did we have a conclusion from this that I just missed?

--
Dean

On Nov 5, 2004, at 9:06 PM, Cullen Jennings wrote:

>
> I think I understand that often the subscriptions is of no use and 
> what you
> want to do here.
>
> It seems like putting a tag in the uri of the refer like ";norefersub" 
> could
> be used as a hint not to create the implicit subscription. It does not 
> seem
> like the Supported Require stuff is needed.
>
> Would this work and do what you want?
>
> Cullen
>
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec 15 16:57:10 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21105
	for <sip-web-archive@ietf.org>; Wed, 15 Dec 2004 16:57:10 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CehHH-0004nu-DE
	for sip-web-archive@ietf.org; Wed, 15 Dec 2004 17:05:48 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CegvB-0001vW-MF; Wed, 15 Dec 2004 16:42:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cegfe-0008Rw-6w
	for sip@megatron.ietf.org; Wed, 15 Dec 2004 16:26:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15740
	for <sip@ietf.org>; Wed, 15 Dec 2004 16:26:51 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cegnv-00039O-Ov
	for sip@ietf.org; Wed, 15 Dec 2004 16:35:29 -0500
Received: from [192.168.0.108] (adsl-209-30-33-13.dsl.rcsntx.swbell.net
	[209.30.33.13]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBFLQgCf078696
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 15 Dec 2004 15:26:44 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <41C0AC11.5080208@nostrum.com>
Date: Wed, 15 Dec 2004 15:26:41 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sip] refer-with-norefersub
References: <BDB17FCD.189BD%fluffy@cisco.com>
In-Reply-To: <BDB17FCD.189BD%fluffy@cisco.com>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Orit Levin <oritl@microsoft.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit

Cullen Jennings wrote:

>I think I understand that often the subscriptions is of no use and what you
>want to do here. 
>
>It seems like putting a tag in the uri of the refer like ";norefersub" could
>be used as a hint not to create the implicit subscription. It does not seem
>like the Supported Require stuff is needed.
>
>Would this work and do what you want?
>  
>

This seems wrong to me -- largely because you're saying that, for 
certain URIs, based on local policy decisions, we are supposed to ignore 
MUST-strength normative statements of RFC3515 (e.g. "The NOTIFY 
mechanism defined in [2] MUST be used to inform the agent sending the 
REFER of the status of the reference.")

It seems very much to me that changing behavior to be noncompliant with 
an RFC requires another RFC.

I could easily formulate scenarios where this proposal actually causes 
interoperability issues, but I believe that the objection on principle 
is sufficiently strong that it's not worth wasting anyone's time 
outlining the practical problems.

/a

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Fri Dec 17 00:20:58 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24823
	for <sip-web-archive@ietf.org>; Fri, 17 Dec 2004 00:20:58 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfAgb-0007fR-Pg
	for sip-web-archive@ietf.org; Fri, 17 Dec 2004 00:29:54 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfART-0005Nw-7N; Fri, 17 Dec 2004 00:14:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfAQI-0004p9-Ko
	for sip@megatron.ietf.org; Fri, 17 Dec 2004 00:13:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24089
	for <sip@ietf.org>; Fri, 17 Dec 2004 00:12:59 -0500 (EST)
Received: from mgw2.alpha.co.jp ([210.250.201.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfAYr-0007Qh-Mv
	for sip@ietf.org; Fri, 17 Dec 2004 00:21:54 -0500
Received: from mgw2.alpha.co.jp (localhost [127.0.0.1])
	by check_out.mgw2.alpha.co.jp (Postfix) with ESMTP id 6F75859611
	for <sip@ietf.org>; Fri, 17 Dec 2004 14:12:34 +0900 (JST)
Received: from sps-0005.alpha.co.jp (sps-0005.alpha.co.jp [10.128.240.3])
	by init.mgw2.alpha.co.jp (Postfix) with SMTP id 292BF1DE806
	for <sip@ietf.org>; Fri, 17 Dec 2004 14:12:34 +0900 (JST)
Date: Fri, 17 Dec 2004 14:12:33 +0900
From: Norihiko Tashi <tashin@alpha.co.jp>
To: sip@ietf.org
Subject: Re: [Sip] Questions about early dialog
In-Reply-To: <005501c4e29d$ef605ff0$7302a8c0@Nataraju>
References: <20041215162145.765B.TASHIN@alpha.co.jp>
	<005501c4e29d$ef605ff0$7302a8c0@Nataraju>
Message-Id: <20041217091944.FEB7.TASHIN@alpha.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.10.04 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Content-Transfer-Encoding: 7bit
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Content-Transfer-Encoding: 7bit

Thanks you for reply.

> Hi,
> 
> I have questions about an INVITE "early" dialog.
> 
> Question 1.
> In an INVITE early dialog, can UA send or process other dialog-
> creating methods(e.g. SUBSCRIBE)?
> 
> If so, SUBSCRIBE messages in the mid-dialog can establish subscriptions.
> 
> In this case, if the first INVITE (dialog-creating) transaction
> terminated later (e.g. non-2xx final response, transport error 
> or timeout) , should the dialog terminate despite existence of 
> subscriptions?
> 
> [ABN] there can be multiple dialogs in a session.... when you send the
> subscribe within session then that creates one more dialog as part of
> the same session....
> when dialog created by INVITE is terminated then dialog created by
> SUBSCRIBE still goes on... in this case only session exists with the
> subscription dialog... 
> 
> Basically there can be multiple dialogs as part of the same session..
> some thing similar to multiple transactions in a dialog...


What does "a session" means?
I think a session in sip specifications is a negotiated state about 
mmedia streams (e.g. by using SDP, SDPng etc..)
between two UAs. 

And, a dialog is a peer-to-peer SIP relationship between two
UAs that persists for some time.
A dialog has dialog identifier and some other informations.
Dialog matching for mid-dialog request will be done by using 
dialog identifier that does not include dialog creating method
information.

In this case, a session and a subscription are higher-layer concept
over a dialog.

So, I think a dialog can be shared by zero or more sessions
(if any, early session/session) and/or zero or more subscriptions.

If there are no sessions and no subscriptions, 
the dialog will terminate because both an INVITE dialog "FSM" 
(doumented in draft-ietf-sipping-dialog-package) and 
an SUBSCRIBE/REFER dialog "FMS"(not subscription state and 
not documented anywhere now) are in terminated state.

The problem in my question is whether the dialog should or not
terminate when "first" dialog creating transaction failed 
after sending or receiving subsequent 
mid-dialog messages (e.g. SUBSCRIBE).

Because if first dialog creating transaction
(that is outside of a dialog) did not succeeded,
subsequent mid-dialog messages could have been existed.

When mid-dialog transaction failed, the dialog will not terminate.



> Question 2.
> 
> A UAS can inform methods that that can be used in the dialog while this
> is
> in the early state as below (RFC3261 13.2.2.1).
> 
> How does a UAC inform methods that can be used 
> in "only" the early dialog?
> 
> Is only solution UAS's reception of a response 
> with "405 Method Not Allowed"?
> 
> [ABN] this may not be required... basic constraint is that, at any point
> in time there can be overlap between INVITE and non-INVITE transactions
> within a dialog. But there CAN'T be multiple INVITE transactions as part
> of the same dialog...
>
> > 13.2.2.1 1xx Responses
> >    The early dialog will only be needed if the UAC needs to send a
> >    request to its peer within the dialog before the initial INVITE
> >    transaction completes.  Header fields present in a provisional
> >    response are applicable as long as the dialog is in the early state
> >    (for example, an Allow header field in a provisional response
> >    contains the methods that can be used in the dialog while this is
> in
> >    the early state).
> 
> [ABN] this does mean that before INVITE transaction completes you can
> send any request other than new INVITE request....
> 
> if you go through RFC3263 about Offer/Answer model you can understand
> this topic pretty well...

The problem is scope of Allow Header.

Allow Header in provisional response with tag is effective
as far as the dialog is in early state (if it was created by INVITE).

And, Allow Header in 2xx response is effective in subsequent
mid-dialog request.

But, Allow Header in INVITE request is effective in both early and
confirm state.

So, A UAS can't get information about methods that can be used 
only in the early dialog.



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Fri Dec 17 05:13:56 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00840
	for <sip-web-archive@ietf.org>; Fri, 17 Dec 2004 05:13:56 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfFG8-0007Ho-P3
	for sip-web-archive@ietf.org; Fri, 17 Dec 2004 05:22:53 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfF6F-0005sG-PF; Fri, 17 Dec 2004 05:12:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfF2s-0005HI-Mc
	for sip@megatron.ietf.org; Fri, 17 Dec 2004 05:09:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00578
	for <sip@ietf.org>; Fri, 17 Dec 2004 05:09:08 -0500 (EST)
Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfFBT-00079f-EX
	for sip@ietf.org; Fri, 17 Dec 2004 05:18:05 -0500
Received: from Nataraju (evi@[192.168.2.115])
	by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id
	iBHA7i814994; Fri, 17 Dec 2004 15:37:46 +0530
From: "Nataraju A B" <bnataraju@kodiaknetworks.com>
To: "'Norihiko Tashi'" <tashin@alpha.co.jp>, <sip@ietf.org>
Subject: RE: [Sip] Questions about early dialog
Date: Fri, 17 Dec 2004 15:32:49 +0530
Message-ID: <000801c4e41f$92abaca0$7302a8c0@Nataraju>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <20041217091944.FEB7.TASHIN@alpha.co.jp>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Content-Transfer-Encoding: 7bit
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
Content-Transfer-Encoding: 7bit



Best Regards,
Nataraju A.B.
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Norihiko Tashi
Sent: Friday, December 17, 2004 10:43 AM
To: sip@ietf.org
Subject: Re: [Sip] Questions about early dialog

Thanks you for reply.

> Hi,
> 
> I have questions about an INVITE "early" dialog.
> 
> Question 1.
> In an INVITE early dialog, can UA send or process other dialog-
> creating methods(e.g. SUBSCRIBE)?
> 
> If so, SUBSCRIBE messages in the mid-dialog can establish
subscriptions.
> 
> In this case, if the first INVITE (dialog-creating) transaction
> terminated later (e.g. non-2xx final response, transport error 
> or timeout) , should the dialog terminate despite existence of 
> subscriptions?
> 
> [ABN] there can be multiple dialogs in a session.... when you send the
> subscribe within session then that creates one more dialog as part of
> the same session....
> when dialog created by INVITE is terminated then dialog created by
> SUBSCRIBE still goes on... in this case only session exists with the
> subscription dialog... 
> 
> Basically there can be multiple dialogs as part of the same session..
> some thing similar to multiple transactions in a dialog...


What does "a session" means?
I think a session in sip specifications is a negotiated state about 
mmedia streams (e.g. by using SDP, SDPng etc..)
between two UAs. 

[ABN] when u send an invite request it will create a dialog as well as a
session which contains only one dialog created by this INVITE request.
Later when u send the subscribe request with same from & To tags as was
used in INVITE transaction then that lead to one more dialog as part of
the same session which was created when INVITE transaction happened.

And, a dialog is a peer-to-peer SIP relationship between two
UAs that persists for some time.
A dialog has dialog identifier and some other informations.
Dialog matching for mid-dialog request will be done by using 
dialog identifier that does not include dialog creating method
information.

In this case, a session and a subscription are higher-layer concept
over a dialog.

[ABN] a dialg will always be part of a session not otherway round...

So, I think a dialog can be shared by zero or more sessions
(if any, early session/session) and/or zero or more subscriptions.

If there are no sessions and no subscriptions, 
the dialog will terminate because both an INVITE dialog "FSM" 
(doumented in draft-ietf-sipping-dialog-package) and 
an SUBSCRIBE/REFER dialog "FMS"(not subscription state and 
not documented anywhere now) are in terminated state.

The problem in my question is whether the dialog should or not
terminate when "first" dialog creating transaction failed 
after sending or receiving subsequent 
mid-dialog messages (e.g. SUBSCRIBE).

Because if first dialog creating transaction
(that is outside of a dialog) did not succeeded,
subsequent mid-dialog messages could have been existed.

When mid-dialog transaction failed, the dialog will not terminate.

[ABN] its other way round session will be terminated only when all the
dialogs as part of that session are deleted. 
[ABN] for instance in your case (INVITE and SUBSCRIPTION) session will
not be deleted once the INVITE's dialog is deleted, that session will be
alive till the subscription dialog is deleted....


> Question 2.
> 
> A UAS can inform methods that that can be used in the dialog while
this
> is
> in the early state as below (RFC3261 13.2.2.1).
> 
> How does a UAC inform methods that can be used 
> in "only" the early dialog?
> 
> Is only solution UAS's reception of a response 
> with "405 Method Not Allowed"?
> 
> [ABN] this may not be required... basic constraint is that, at any
point
> in time there can be overlap between INVITE and non-INVITE
transactions
> within a dialog. But there CAN'T be multiple INVITE transactions as
part
> of the same dialog...
>
> > 13.2.2.1 1xx Responses
> >    The early dialog will only be needed if the UAC needs to send a
> >    request to its peer within the dialog before the initial INVITE
> >    transaction completes.  Header fields present in a provisional
> >    response are applicable as long as the dialog is in the early
state
> >    (for example, an Allow header field in a provisional response
> >    contains the methods that can be used in the dialog while this is
> in
> >    the early state).
> 
> [ABN] this does mean that before INVITE transaction completes you can
> send any request other than new INVITE request....
> 
> if you go through RFC3263 about Offer/Answer model you can understand
> this topic pretty well...

The problem is scope of Allow Header.

Allow Header in provisional response with tag is effective
as far as the dialog is in early state (if it was created by INVITE).

And, Allow Header in 2xx response is effective in subsequent
mid-dialog request.

But, Allow Header in INVITE request is effective in both early and
confirm state.

So, A UAS can't get information about methods that can be used 
only in the early dialog.



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Fri Dec 17 08:49:47 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18718
	for <sip-web-archive@ietf.org>; Fri, 17 Dec 2004 08:49:47 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfId2-0005C2-A0
	for sip-web-archive@ietf.org; Fri, 17 Dec 2004 08:58:45 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfIQ4-0002jv-DY; Fri, 17 Dec 2004 08:45:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfIOv-0002M0-2u
	for sip@megatron.ietf.org; Fri, 17 Dec 2004 08:44:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18314
	for <sip@ietf.org>; Fri, 17 Dec 2004 08:44:07 -0500 (EST)
Message-Id: <200412171344.IAA18314@ietf.org>
Received: from [202.108.44.212] (helo=163.com)
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CfIXX-000538-4B
	for sip@ietf.org; Fri, 17 Dec 2004 08:53:05 -0500
Received: from Liuyang (unknown [202.112.110.166])
	by smtp4 (Coremail) with SMTP id GoCuBOXiwkEUkygE.1
	for <sip@ietf.org>; Fri, 17 Dec 2004 21:45:13 +0800 (CST)
X-Originating-IP: [202.112.110.166]
Date: Fri, 17 Dec 2004 21:48:26 +0800
From: "liuyang" <liuyang5599@163.com>
To: "sip" <sip@ietf.org>
X-mailer: Foxmail 5.0 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.4 (+++)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7bit
Subject: [Sip] (no subject)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 4.1 (++++)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit

Merry christmas.
     Inow i am working on a b project about sip 
 compression,but i am a beginer in this field,i wanna ask you 
 a question: is there any open source project on SIP compression and
 where 
 can i find it?
  
   your reply will help us a lot ?





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Fri Dec 17 14:43:08 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25605
	for <sip-web-archive@ietf.org>; Fri, 17 Dec 2004 14:43:08 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfO92-0000h2-BW
	for sip-web-archive@ietf.org; Fri, 17 Dec 2004 14:52:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfNxi-0002rB-Cy; Fri, 17 Dec 2004 14:40:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfNsJ-0001S2-Ly
	for sip@megatron.ietf.org; Fri, 17 Dec 2004 14:34:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24869
	for <sip@ietf.org>; Fri, 17 Dec 2004 14:34:50 -0500 (EST)
Received: from machine76.level3.com ([209.244.4.189] helo=scanner5.level3.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfO10-0000Q8-KI
	for sip@ietf.org; Fri, 17 Dec 2004 14:43:50 -0500
Received: from scanner5.level3.com (localhost [127.0.0.1])
	by localhost.level3.com (Postfix) with ESMTP id BEC931251F9
	for <sip@ietf.org>; Fri, 17 Dec 2004 19:34:10 +0000 (GMT)
Received: from idc1exc0001.corp.global.level3.com
	(idc1exc0001.corp.global.level3.com [10.1.7.194])
	by scanner5.level3.com (Postfix) with SMTP id 4B7751250EC
	for <sip@ietf.org>; Fri, 17 Dec 2004 19:34:10 +0000 (GMT)
Received: from idc1exc0002.corp.global.level3.com ([10.1.8.18]) by
	idc1exc0001.corp.global.level3.com with Microsoft
	SMTPSVC(6.0.3790.211); Fri, 17 Dec 2004 12:34:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Dec 2004 12:34:09 -0700
Message-ID: <11FD90E74279C0489ECB6793F227C847044BFBDE@idc1exc0002.corp.global.level3.com>
Thread-Topic: a question about the tag in From or To header
Thread-Index: AcTkb2FD4ROBONplR/uzXICJiEJXWA==
From: "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com>
To: <sip@ietf.org>
X-OriginalArrivalTime: 17 Dec 2004 19:34:09.0951 (UTC)
	FILETIME=[6161AAF0:01C4E46F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] a question about the tag in From or To header
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: quoted-printable

We have a debate on how to interpret the following paragraph (RFC 3261, =
section 19.3):

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
19.3 Tags
   ...

   When a tag is generated by a UA for insertion into a request or
   response, it MUST be globally unique and cryptographically random
   with at least 32 bits of randomness.  A property of this selection
   requirement is that a UA will place a different tag into the From
   header of an INVITE than it would place into the To header of the
   response to the same INVITE.  This is needed in order for a UA to
   invite itself to a session, a common case for "hairpinning" of calls
   in PSTN gateways.  Similarly, two INVITEs for different calls will
   have different From tags, and two responses for different calls will
   have different To tags.

   ...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Interpretation 1: A tag needs to be globally unique across space (aka =
UAs) but not across time because Call-ID (section 8.1.1.4) is already =
unique across space and time for calls. So a same UAC can use a same =
>From tag in different calls it imitates. And a same UAS can use a same =
To tag to respond to different calls. A same UA uses different tags in =
>From and To headers. Different UAs use different tags.

Interpretation 2: A tag needs to be different for each call. So a same =
UAC has to use two different tags in From header when it initiates two =
different calls. And a same UAS has to use different tags in To headers =
for different calls.=20

We would like to hear from the list which way we should interpret the =
above paragraph or what is the right interpretation if both =
interpretations are not accurate.

Thanks.


Jin-Gen Wang
Level3 Communications, Inc.



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Sat Dec 18 01:55:11 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10191
	for <sip-web-archive@ietf.org>; Sat, 18 Dec 2004 01:55:11 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfYdV-0001FR-CJ
	for sip-web-archive@ietf.org; Sat, 18 Dec 2004 02:04:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfYT2-0004i1-MA; Sat, 18 Dec 2004 01:53:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfYNQ-0003Xo-H9
	for sip@megatron.ietf.org; Sat, 18 Dec 2004 01:47:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09651
	for <sip@ietf.org>; Sat, 18 Dec 2004 01:47:39 -0500 (EST)
Received: from web14702.mail.yahoo.com ([216.136.224.119])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CfYWC-00011A-Pr
	for sip@ietf.org; Sat, 18 Dec 2004 01:56:46 -0500
Received: (qmail 36281 invoked by uid 60001); 18 Dec 2004 06:47:32 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	b=n93Qs0+qw/Ua7mPunLykeRrHoSF9EriogmoeLzFlQ+h4rfh+lVL8MXRJfX1PhS3CkoyAcv5qMtyUQLKQGr615cmzcuLSkMIGivY+2SRotaKqzi9MpGG/S8JPEu3ylvaGN6MMyq3sJzFD4AC/rHs1OK9O3c06EfcCj7FhlH4r/eI=
	; 
Message-ID: <20041218064732.36279.qmail@web14702.mail.yahoo.com>
Received: from [217.29.240.34] by web14702.mail.yahoo.com via HTTP;
	Fri, 17 Dec 2004 22:47:32 PST
Date: Fri, 17 Dec 2004 22:47:32 -0800 (PST)
From: mazen alhasan <mazen_m9@yahoo.com>
To: sip@ietf.org
MIME-Version: 1.0
X-Spam-Score: 2.7 (++)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Subject: [Sip] i am new member
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0324026719=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034

--===============0324026719==
Content-Type: multipart/alternative; boundary="0-887552892-1103352452=:35952"

--0-887552892-1103352452=:35952
Content-Type: text/plain; charset=us-ascii

hi fo all, i want to know how sip proxy server works.

		
---------------------------------
Do you Yahoo!?
 Take Yahoo! Mail with you! Get it on your mobile phone.
--0-887552892-1103352452=:35952
Content-Type: text/html; charset=us-ascii

<DIV>hi fo all, i want to know how sip proxy server works.</DIV><p>
		<hr size=1>Do you Yahoo!?<br> 
<a href="http://us.rd.yahoo.com/mail_us/taglines/mobile/*http://mobile.yahoo.com/maildemo">Take Yahoo! Mail with you!</a> Get it on your mobile phone.
--0-887552892-1103352452=:35952--


--===============0324026719==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0324026719==--



From sip-bounces@ietf.org  Sat Dec 18 02:42:36 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27693
	for <sip-web-archive@ietf.org>; Sat, 18 Dec 2004 02:42:34 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfZNH-0002Nw-TL
	for sip-web-archive@ietf.org; Sat, 18 Dec 2004 02:51:42 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CfZ7v-0002pR-Fd; Sat, 18 Dec 2004 02:35:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CeCCt-0002Jq-FQ
	for sip@megatron.ietf.org; Tue, 14 Dec 2004 07:55:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21093
	for <sip@ietf.org>; Tue, 14 Dec 2004 07:55:09 -0500 (EST)
Received: from ip-207-145-48-18.sjc.megapath.net ([207.145.48.18])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CeCKm-0007TC-3B
	for sip@ietf.org; Tue, 14 Dec 2004 08:03:27 -0500
Received: from brahma.intotoind.com ([66.80.10.146])
	by ip-207-145-48-18.sjc.megapath.net (SMSSMTP 4.0.0.59) with SMTP id
	M2004121404540519757
	for <sip@ietf.org>; Tue, 14 Dec 2004 04:54:05 -0800
Received: from surya.intoto.com (2mc100.intotoind.com [172.16.2.100])
	by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id iBECsKrR013520
	for <sip@ietf.org>; Tue, 14 Dec 2004 18:24:20 +0530
Message-Id: <6.1.2.0.0.20041214180038.02490030@172.16.1.10>
X-Sender: asurya@172.16.1.10
X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0
Date: Tue, 14 Dec 2004 18:25:54 +0530
To: sip@ietf.org
From: Surya Santosh <asurya@intoto.com>
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.41
X-Spam-Score: 0.8 (/)
X-Scan-Signature: f323452a3aff82975a792c55734c117b
X-Mailman-Approved-At: Sat, 18 Dec 2004 02:34:50 -0500
Subject: [Sip] Retransmission of 200 OK after receiving ACK
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1965576048=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 259a4199be4d743b1a7193f9313e36ac

--===============1965576048==
Content-Type: multipart/alternative;
	boundary="=====================_6427312==.ALT"

--=====================_6427312==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi All,

I have a doubt regarding the processing of ACK  by the UA. The UA , even 
after receving ACK from the other UA is still sending 200 OK's.

I am using the following configuration.

Host1------------Firewall---------------------------Internet
                                          |
                                          |
                                        Host2

I am using AOL instant messenger on both the hosts. I started video from 
Host2 to Host1. As AOL video uses SIP for connection establishment, Host1 
sends SIP INVITE to HOST2 and the following figure depicts the flow of the 
packets between the two UA's.

Host1--------------------------------------Host2
INVITE---------------------->
           <---------------------  100 Trying
           <---------------------  180 Ringing
           <---------------------- 200 OK
ACK    ----------------------->

After receiving the ACK, Host 2 is still sending 200 OK's . It is happening 
often but not all the times.
I have attached the capture of  failure case. Could anyone please help me 
in finding out why Host2 is sending 200 OK' s even after receiving ACK.


Failure Case
Capture At Internal Machine (HOST 1)
No.     Time        Source                Destination           Protocol Info
      68 
14.197405   10.1.6.5              202.125.84.171        SIP/SDP  Request: 
INVITE sip:user@202.125.84.171:1571, with session description

Frame 68 (1078 bytes on wire, 1078 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:06.384363000
     Time delta from previous packet: 14.197405000 seconds
     Time since reference or first frame: 14.197405000 seconds
     Frame Number: 68
     Packet Length: 1078 bytes
     Capture Length: 1078 bytes
Ethernet II, Src: 00:50:fc:b1:ea:9d, Dst: 00:00:24:c2:01:f4
     Destination: 00:00:24:c2:01:f4 (10.1.6.1)
     Source: 00:50:fc:b1:ea:9d (10.1.6.5)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 10.1.6.5 (10.1.6.5), Dst Addr: 202.125.84.171 
(202.125.84.171)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 1064
     Identification: 0xd3d4 (54228)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x33c2 (correct)
     Source: 10.1.6.5 (10.1.6.5)
     Destination: 202.125.84.171 (202.125.84.171)
User Datagram Protocol, Src Port: 1208 (1208), Dst Port: 1571 (1571)
     Source port: 1208 (1208)
     Destination port: 1571 (1571)
     Length: 1044
     Checksum: 0x69e1 (correct)
Session Initiation Protocol
     Request-Line: INVITE sip:user@202.125.84.171:1571 SIP/2.0
         Method: INVITE
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 10.1.6.5:1208
         Max-Forwards: 70
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>
             SIP to address: sip:user@202.125.84.171
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5
         CSeq: 1 INVITE
         Contact: <sip:10.1.6.5:1208>
         User-Agent: RTC/1.2
         Content-Type: application/sdp
         Content-Length: 667
     Message body
         Session Description Protocol
             Session Description Protocol Version (v): 0
             Owner/Creator, Session Id (o): - 0 0 IN IP4 10.1.6.5
                 Owner Username: -
                 Session ID: 0
                 Session Version: 0
                 Owner Network Type: IN
                 Owner Address Type: IP4
                 Owner Address: 10.1.6.5
             Session Name (s): session
             Connection Information (c): IN IP4 10.1.6.5
                 Connection Network Type: IN
                 Connection Address Type: IP4
                 Connection Address: 10.1.6.5
             Bandwidth Information (b): CT:1000
                 Bandwidth Modifier: CT
                 Bandwidth Value: 1000
             Time Description, active time (t): 0 0
                 Session Start Time: 0
                 Session Stop Time: 0
             Media Description, name and address (m): audio 1211 RTP/AVP 97 
111 112 6 0 8 4 5 3 101
                 Media Type: audio
                 Media Port: 1211
                 Media Proto: RTP/AVP
                 Media Format: 97
                 Media Format: 111
                 Media Format: 112
                 Media Format: DVI4 16000 samples/s
                 Media Format: ITU-T G.711 PCMU
                 Media Format: ITU-T G.711 PCMA
                 Media Format: ITU-T G.723
                 Media Format: DVI4 8000 samples/s
                 Media Format: GSM 06.10
                 Media Format: 101
             Encryption Key (k): 
base64:aINkrSXVFlOw/LgTKp5bHe1D1a/vQi7wV59gwbXEtRY
                 Key Type: base64
                 Key Data: aINkrSXVFlOw/LgTKp5bHe1D1a/vQi7wV59gwbXEtRY
             Media Attribute (a): rtpmap:97 red/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 97 red/8000
             Media Attribute (a): rtpmap:111 SIREN/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 111 SIREN/16000
             Media Attribute (a): fmtp:111 bitrate=16000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 111 bitrate=16000
             Media Attribute (a): rtpmap:112 G7221/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 112 G7221/16000
             Media Attribute (a): fmtp:112 bitrate=24000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 112 bitrate=24000
             Media Attribute (a): rtpmap:6 DVI4/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 6 DVI4/16000
             Media Attribute (a): rtpmap:0 PCMU/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 0 PCMU/8000
             Media Attribute (a): rtpmap:8 PCMA/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 8 PCMA/8000
             Media Attribute (a): rtpmap:4 G723/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 4 G723/8000
             Media Attribute (a): rtpmap:5 DVI4/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 5 DVI4/8000
             Media Attribute (a): rtpmap:3 GSM/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 3 GSM/8000
             Media Attribute (a): rtpmap:101 telephone-event/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 101 telephone-event/8000
             Media Attribute (a): fmtp:101 0-16
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 101 0-16
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional
             Media Description, name and address (m): video 1209 RTP/AVP 34 31
                 Media Type: video
                 Media Port: 1209
                 Media Proto: RTP/AVP
                 Media Format: ITU-T H.263
                 Media Format: ITU-T H.261
             Encryption Key (k): 
base64:9X9PloS9X/sgFGWluGGzdFVMn9iEMyaOMVKenrIlfYw
                 Key Type: base64
                 Key Data: 9X9PloS9X/sgFGWluGGzdFVMn9iEMyaOMVKenrIlfYw
             Media Attribute (a): rtpmap:34 H263/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 34 H263/90000
             Media Attribute (a): rtpmap:31 H261/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 31 H261/90000
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional

No.     Time        Source                Destination           Protocol Info
      69 
14.208670   202.125.84.171        10.1.6.5              SIP      Status: 
100 Trying

Frame 69 (337 bytes on wire, 337 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:06.395628000
     Time delta from previous packet: 0.011265000 seconds
     Time since reference or first frame: 14.208670000 seconds
     Frame Number: 69
     Packet Length: 337 bytes
     Capture Length: 337 bytes
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d
     Destination: 00:50:fc:b1:ea:9d (10.1.6.5)
     Source: 00:00:24:c2:01:f4 (10.1.6.1)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
10.1.6.5 (10.1.6.5)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 323
     Identification: 0xd91e (55582)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 127
     Protocol: UDP (0x11)
     Header checksum: 0x325d (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 10.1.6.5 (10.1.6.5)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 (1208)
     Source port: 1571 (1571)
     Destination port: 1208 (1208)
     Length: 303
     Checksum: 0xd0fb (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 100 Trying
         Status-Code: 100
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 10.1.6.5
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5
         CSeq: 1 INVITE
         User-Agent: RTC/1.2
         Content-Length: 0

No.     Time        Source                Destination           Protocol Info
      70 
14.209958   202.125.84.171        10.1.6.5              SIP      Status: 
180 Ringing

Frame 70 (338 bytes on wire, 338 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:06.396916000
     Time delta from previous packet: 0.001288000 seconds
     Time since reference or first frame: 14.209958000 seconds
     Frame Number: 70
     Packet Length: 338 bytes
     Capture Length: 338 bytes
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d
     Destination: 00:50:fc:b1:ea:9d (10.1.6.5)
     Source: 00:00:24:c2:01:f4 (10.1.6.1)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
10.1.6.5 (10.1.6.5)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 324
     Identification: 0xd91f (55583)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 127
     Protocol: UDP (0x11)
     Header checksum: 0x325b (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 10.1.6.5 (10.1.6.5)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 (1208)
     Source port: 1571 (1571)
     Destination port: 1208 (1208)
     Length: 304
     Checksum: 0x9ad6 (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 180 Ringing
         Status-Code: 180
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 10.1.6.5
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5
         CSeq: 1 INVITE
         User-Agent: RTC/1.2
         Content-Length: 0

No.     Time        Source                Destination           Protocol Info
      71 
14.553022   202.125.84.171        10.1.6.5              SIP/SDP  Status: 
200 OK, with session description

Frame 71 (1081 bytes on wire, 1081 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:06.739980000
     Time delta from previous packet: 0.343064000 seconds
     Time since reference or first frame: 14.553022000 seconds
     Frame Number: 71
     Packet Length: 1081 bytes
     Capture Length: 1081 bytes
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d
     Destination: 00:50:fc:b1:ea:9d (10.1.6.5)
     Source: 00:00:24:c2:01:f4 (10.1.6.1)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
10.1.6.5 (10.1.6.5)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 1067
     Identification: 0xd920 (55584)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 127
     Protocol: UDP (0x11)
     Header checksum: 0x2f73 (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 10.1.6.5 (10.1.6.5)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 (1208)
     Source port: 1571 (1571)
     Destination port: 1208 (1208)
     Length: 1047
     Checksum: 0x39bc (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 200 OK
         Status-Code: 200
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 10.1.6.5
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5
         CSeq: 1 INVITE
         Contact: <sip:202.125.84.171:1571>
         User-Agent: RTC/1.2
         Content-Type: application/sdp
         Content-Length: 679
     Message body
         Session Description Protocol
             Session Description Protocol Version (v): 0
             Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171
                 Owner Username: -
                 Session ID: 0
                 Session Version: 0
                 Owner Network Type: IN
                 Owner Address Type: IP4
                 Owner Address: 202.125.84.171
             Session Name (s): session
             Connection Information (c): IN IP4 202.125.84.171
                 Connection Network Type: IN
                 Connection Address Type: IP4
                 Connection Address: 202.125.84.171
             Bandwidth Information (b): CT:1000
                 Bandwidth Modifier: CT
                 Bandwidth Value: 1000
             Time Description, active time (t): 0 0
                 Session Start Time: 0
                 Session Stop Time: 0
             Media Description, name and address (m): audio 1572 RTP/AVP 97 
111 112 6 0 8 4 5 3 101
                 Media Type: audio
                 Media Port: 1572
                 Media Proto: RTP/AVP
                 Media Format: 97
                 Media Format: 111
                 Media Format: 112
                 Media Format: DVI4 16000 samples/s
                 Media Format: ITU-T G.711 PCMU
                 Media Format: ITU-T G.711 PCMA
                 Media Format: ITU-T G.723
                 Media Format: DVI4 8000 samples/s
                 Media Format: GSM 06.10
                 Media Format: 101
             Encryption Key (k): 
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
                 Key Type: base64
                 Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
             Media Attribute (a): rtpmap:97 red/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 97 red/8000
             Media Attribute (a): rtpmap:111 SIREN/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 111 SIREN/16000
             Media Attribute (a): fmtp:111 bitrate=16000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 111 bitrate=16000
             Media Attribute (a): rtpmap:112 G7221/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 112 G7221/16000
             Media Attribute (a): fmtp:112 bitrate=24000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 112 bitrate=24000
             Media Attribute (a): rtpmap:6 DVI4/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 6 DVI4/16000
             Media Attribute (a): rtpmap:0 PCMU/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 0 PCMU/8000
             Media Attribute (a): rtpmap:8 PCMA/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 8 PCMA/8000
             Media Attribute (a): rtpmap:4 G723/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 4 G723/8000
             Media Attribute (a): rtpmap:5 DVI4/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 5 DVI4/8000
             Media Attribute (a): rtpmap:3 GSM/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 3 GSM/8000
             Media Attribute (a): rtpmap:101 telephone-event/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 101 telephone-event/8000
             Media Attribute (a): fmtp:101 0-16
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 101 0-16
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional
             Media Description, name and address (m): video 1574 RTP/AVP 34 31
                 Media Type: video
                 Media Port: 1574
                 Media Proto: RTP/AVP
                 Media Format: ITU-T H.263
                 Media Format: ITU-T H.261
             Encryption Key (k): 
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
                 Key Type: base64
                 Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
             Media Attribute (a): rtpmap:34 H263/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 34 H263/90000
             Media Attribute (a): rtpmap:31 H261/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 31 H261/90000
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional

No.     Time        Source                Destination           Protocol Info
      73 
15.042612   202.125.84.171        10.1.6.5              SIP/SDP  Status: 
200 OK, with session description

Frame 73 (1081 bytes on wire, 1081 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:07.229570000
     Time delta from previous packet: 0.489590000 seconds
     Time since reference or first frame: 15.042612000 seconds
     Frame Number: 73
     Packet Length: 1081 bytes
     Capture Length: 1081 bytes
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d
     Destination: 00:50:fc:b1:ea:9d (10.1.6.5)
     Source: 00:00:24:c2:01:f4 (10.1.6.1)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
10.1.6.5 (10.1.6.5)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 1067
     Identification: 0xd921 (55585)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 127
     Protocol: UDP (0x11)
     Header checksum: 0x2f72 (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 10.1.6.5 (10.1.6.5)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 (1208)
     Source port: 1571 (1571)
     Destination port: 1208 (1208)
     Length: 1047
     Checksum: 0x39bc (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 200 OK
         Status-Code: 200
         Resent Packet: True
         Suspected resend of frame: 71
     Message Header
         Via: SIP/2.0/UDP 10.1.6.5
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5
         CSeq: 1 INVITE
         Contact: <sip:202.125.84.171:1571>
         User-Agent: RTC/1.2
         Content-Type: application/sdp
         Content-Length: 679
     Message body
         Session Description Protocol
             Session Description Protocol Version (v): 0
             Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171
                 Owner Username: -
                 Session ID: 0
                 Session Version: 0
                 Owner Network Type: IN
                 Owner Address Type: IP4
                 Owner Address: 202.125.84.171
             Session Name (s): session
             Connection Information (c): IN IP4 202.125.84.171
                 Connection Network Type: IN
                 Connection Address Type: IP4
                 Connection Address: 202.125.84.171
             Bandwidth Information (b): CT:1000
                 Bandwidth Modifier: CT
                 Bandwidth Value: 1000
             Time Description, active time (t): 0 0
                 Session Start Time: 0
                 Session Stop Time: 0
             Media Description, name and address (m): audio 1572 RTP/AVP 97 
111 112 6 0 8 4 5 3 101
                 Media Type: audio
                 Media Port: 1572
                 Media Proto: RTP/AVP
                 Media Format: 97
                 Media Format: 111
                 Media Format: 112
                 Media Format: DVI4 16000 samples/s
                 Media Format: ITU-T G.711 PCMU
                 Media Format: ITU-T G.711 PCMA
                 Media Format: ITU-T G.723
                 Media Format: DVI4 8000 samples/s
                 Media Format: GSM 06.10
                 Media Format: 101
             Encryption Key (k): 
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
                 Key Type: base64
                 Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
             Media Attribute (a): rtpmap:97 red/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 97 red/8000
             Media Attribute (a): rtpmap:111 SIREN/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 111 SIREN/16000
             Media Attribute (a): fmtp:111 bitrate=16000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 111 bitrate=16000
             Media Attribute (a): rtpmap:112 G7221/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 112 G7221/16000
             Media Attribute (a): fmtp:112 bitrate=24000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 112 bitrate=24000
             Media Attribute (a): rtpmap:6 DVI4/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 6 DVI4/16000
             Media Attribute (a): rtpmap:0 PCMU/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 0 PCMU/8000
             Media Attribute (a): rtpmap:8 PCMA/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 8 PCMA/8000
             Media Attribute (a): rtpmap:4 G723/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 4 G723/8000
             Media Attribute (a): rtpmap:5 DVI4/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 5 DVI4/8000
             Media Attribute (a): rtpmap:3 GSM/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 3 GSM/8000
             Media Attribute (a): rtpmap:101 telephone-event/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 101 telephone-event/8000
             Media Attribute (a): fmtp:101 0-16
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 101 0-16
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional
             Media Description, name and address (m): video 1574 RTP/AVP 34 31
                 Media Type: video
                 Media Port: 1574
                 Media Proto: RTP/AVP
                 Media Format: ITU-T H.263
                 Media Format: ITU-T H.261
             Encryption Key (k): 
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
                 Key Type: base64
                 Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
             Media Attribute (a): rtpmap:34 H263/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 34 H263/90000
             Media Attribute (a): rtpmap:31 H261/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 31 H261/90000
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional

No.     Time        Source                Destination           Protocol Info
     121 
16.043599   202.125.84.171        10.1.6.5              SIP/SDP  Status: 
200 OK, with session description

Frame 121 (1081 bytes on wire, 1081 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:08.230557000
     Time delta from previous packet: 1.000987000 seconds
     Time since reference or first frame: 16.043599000 seconds
     Frame Number: 121
     Packet Length: 1081 bytes
     Capture Length: 1081 bytes
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d
     Destination: 00:50:fc:b1:ea:9d (10.1.6.5)
     Source: 00:00:24:c2:01:f4 (10.1.6.1)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
10.1.6.5 (10.1.6.5)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 1067
     Identification: 0xd923 (55587)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 127
     Protocol: UDP (0x11)
     Header checksum: 0x2f70 (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 10.1.6.5 (10.1.6.5)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 (1208)
     Source port: 1571 (1571)
     Destination port: 1208 (1208)
     Length: 1047
     Checksum: 0x39bc (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 200 OK
         Status-Code: 200
         Resent Packet: True
         Suspected resend of frame: 71
     Message Header
         Via: SIP/2.0/UDP 10.1.6.5
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5
         CSeq: 1 INVITE
         Contact: <sip:202.125.84.171:1571>
         User-Agent: RTC/1.2
         Content-Type: application/sdp
         Content-Length: 679
     Message body
         Session Description Protocol
             Session Description Protocol Version (v): 0
             Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171
                 Owner Username: -
                 Session ID: 0
                 Session Version: 0
                 Owner Network Type: IN
                 Owner Address Type: IP4
                 Owner Address: 202.125.84.171
             Session Name (s): session
             Connection Information (c): IN IP4 202.125.84.171
                 Connection Network Type: IN
                 Connection Address Type: IP4
                 Connection Address: 202.125.84.171
             Bandwidth Information (b): CT:1000
                 Bandwidth Modifier: CT
                 Bandwidth Value: 1000
             Time Description, active time (t): 0 0
                 Session Start Time: 0
                 Session Stop Time: 0
             Media Description, name and address (m): audio 1572 RTP/AVP 97 
111 112 6 0 8 4 5 3 101
                 Media Type: audio
                 Media Port: 1572
                 Media Proto: RTP/AVP
                 Media Format: 97
                 Media Format: 111
                 Media Format: 112
                 Media Format: DVI4 16000 samples/s
                 Media Format: ITU-T G.711 PCMU
                 Media Format: ITU-T G.711 PCMA
                 Media Format: ITU-T G.723
                 Media Format: DVI4 8000 samples/s
                 Media Format: GSM 06.10
                 Media Format: 101
             Encryption Key (k): 
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
                 Key Type: base64
                 Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
             Media Attribute (a): rtpmap:97 red/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 97 red/8000
             Media Attribute (a): rtpmap:111 SIREN/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 111 SIREN/16000
             Media Attribute (a): fmtp:111 bitrate=16000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 111 bitrate=16000
             Media Attribute (a): rtpmap:112 G7221/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 112 G7221/16000
             Media Attribute (a): fmtp:112 bitrate=24000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 112 bitrate=24000
             Media Attribute (a): rtpmap:6 DVI4/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 6 DVI4/16000
             Media Attribute (a): rtpmap:0 PCMU/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 0 PCMU/8000
             Media Attribute (a): rtpmap:8 PCMA/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 8 PCMA/8000
             Media Attribute (a): rtpmap:4 G723/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 4 G723/8000
             Media Attribute (a): rtpmap:5 DVI4/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 5 DVI4/8000
             Media Attribute (a): rtpmap:3 GSM/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 3 GSM/8000
             Media Attribute (a): rtpmap:101 telephone-event/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 101 telephone-event/8000
             Media Attribute (a): fmtp:101 0-16
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 101 0-16
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional
             Media Description, name and address (m): video 1574 RTP/AVP 34 31
                 Media Type: video
                 Media Port: 1574
                 Media Proto: RTP/AVP
                 Media Format: ITU-T H.263
                 Media Format: ITU-T H.261
             Encryption Key (k): 
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
                 Key Type: base64
                 Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
             Media Attribute (a): rtpmap:34 H263/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 34 H263/90000
             Media Attribute (a): rtpmap:31 H261/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 31 H261/90000
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional

No.     Time        Source                Destination           Protocol Info
     166 
16.881442   10.1.6.5              202.125.84.171        SIP      Request: 
ACK sip:202.125.84.171:1571

Frame 166 (374 bytes on wire, 374 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:09.068400000
     Time delta from previous packet: 0.837843000 seconds
     Time since reference or first frame: 16.881442000 seconds
     Frame Number: 166
     Packet Length: 374 bytes
     Capture Length: 374 bytes
Ethernet II, Src: 00:50:fc:b1:ea:9d, Dst: 00:00:24:c2:01:f4
     Destination: 00:00:24:c2:01:f4 (10.1.6.1)
     Source: 00:50:fc:b1:ea:9d (10.1.6.5)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 10.1.6.5 (10.1.6.5), Dst Addr: 202.125.84.171 
(202.125.84.171)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 360
     Identification: 0xd431 (54321)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x3625 (correct)
     Source: 10.1.6.5 (10.1.6.5)
     Destination: 202.125.84.171 (202.125.84.171)
User Datagram Protocol, Src Port: 1208 (1208), Dst Port: 1571 (1571)
     Source port: 1208 (1208)
     Destination port: 1571 (1571)
     Length: 340
     Checksum: 0x37c0 (correct)
Session Initiation Protocol
     Request-Line: ACK sip:202.125.84.171:1571 SIP/2.0
         Method: ACK
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 10.1.6.5:1208
         Max-Forwards: 70
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5
         CSeq: 1 ACK
         User-Agent: RTC/1.2
         Content-Length: 0

No.     Time        Source                Destination           Protocol Info
     176 
17.012456   10.1.6.5              202.125.84.171        SIP      Request: 
ACK sip:202.125.84.171:1571

Frame 176 (374 bytes on wire, 374 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:09.199414000
     Time delta from previous packet: 0.131014000 seconds
     Time since reference or first frame: 17.012456000 seconds
     Frame Number: 176
     Packet Length: 374 bytes
     Capture Length: 374 bytes
Ethernet II, Src: 00:50:fc:b1:ea:9d, Dst: 00:00:24:c2:01:f4
     Destination: 00:00:24:c2:01:f4 (10.1.6.1)
     Source: 00:50:fc:b1:ea:9d (10.1.6.5)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 10.1.6.5 (10.1.6.5), Dst Addr: 202.125.84.171 
(202.125.84.171)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 360
     Identification: 0xd43a (54330)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x361c (correct)
     Source: 10.1.6.5 (10.1.6.5)
     Destination: 202.125.84.171 (202.125.84.171)
User Datagram Protocol, Src Port: 1208 (1208), Dst Port: 1571 (1571)
     Source port: 1208 (1208)
     Destination port: 1571 (1571)
     Length: 340
     Checksum: 0x37c0 (correct)
Session Initiation Protocol
     Request-Line: ACK sip:202.125.84.171:1571 SIP/2.0
         Method: ACK
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 10.1.6.5:1208
         Max-Forwards: 70
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5
         CSeq: 1 ACK
         User-Agent: RTC/1.2
         Content-Length: 0

No.     Time        Source                Destination           Protocol Info
     178 
17.041945   10.1.6.5              202.125.84.171        SIP      Request: 
ACK sip:202.125.84.171:1571

Frame 178 (374 bytes on wire, 374 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:09.228903000
     Time delta from previous packet: 0.029489000 seconds
     Time since reference or first frame: 17.041945000 seconds
     Frame Number: 178
     Packet Length: 374 bytes
     Capture Length: 374 bytes
Ethernet II, Src: 00:50:fc:b1:ea:9d, Dst: 00:00:24:c2:01:f4
     Destination: 00:00:24:c2:01:f4 (10.1.6.1)
     Source: 00:50:fc:b1:ea:9d (10.1.6.5)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 10.1.6.5 (10.1.6.5), Dst Addr: 202.125.84.171 
(202.125.84.171)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 360
     Identification: 0xd43c (54332)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x361a (correct)
     Source: 10.1.6.5 (10.1.6.5)
     Destination: 202.125.84.171 (202.125.84.171)
User Datagram Protocol, Src Port: 1208 (1208), Dst Port: 1571 (1571)
     Source port: 1208 (1208)
     Destination port: 1571 (1571)
     Length: 340
     Checksum: 0x37c0 (correct)
Session Initiation Protocol
     Request-Line: ACK sip:202.125.84.171:1571 SIP/2.0
         Method: ACK
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 10.1.6.5:1208
         Max-Forwards: 70
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5
         CSeq: 1 ACK
         User-Agent: RTC/1.2
         Content-Length: 0

No.     Time        Source                Destination           Protocol Info
    2978 
78.302363   202.125.84.171        10.1.6.5              SIP      Request: 
BYE sip:10.1.6.5:60324

Frame 2978 (375 bytes on wire, 375 bytes captured)
     Arrival Time: Dec 14, 2004 11:36:10.489321000
     Time delta from previous packet: 61.260418000 seconds
     Time since reference or first frame: 78.302363000 seconds
     Frame Number: 2978
     Packet Length: 375 bytes
     Capture Length: 375 bytes
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d
     Destination: 00:50:fc:b1:ea:9d (10.1.6.5)
     Source: 00:00:24:c2:01:f4 (10.1.6.1)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
10.1.6.5 (10.1.6.5)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 361
     Identification: 0xd965 (55653)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 127
     Protocol: UDP (0x11)
     Header checksum: 0x31f0 (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 10.1.6.5 (10.1.6.5)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 (1208)
     Source port: 1571 (1571)
     Destination port: 1208 (1208)
     Length: 341
     Checksum: 0xbde1 (correct)
Session Initiation Protocol
     Request-Line: BYE sip:10.1.6.5:60324 SIP/2.0
         Method: BYE
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 202.125.84.171:1571
         Max-Forwards: 70
         From: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP from address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         To: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP to address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5
         CSeq: 1 BYE
         User-Agent: RTC/1.2
         Content-Length: 0

No.     Time        Source                Destination           Protocol Info
    2993 
78.789133   202.125.84.171        10.1.6.5              SIP      Request: 
BYE sip:10.1.6.5:60324

Frame 2993 (375 bytes on wire, 375 bytes captured)
     Arrival Time: Dec 14, 2004 11:36:10.976091000
     Time delta from previous packet: 0.486770000 seconds
     Time since reference or first frame: 78.789133000 seconds
     Frame Number: 2993
     Packet Length: 375 bytes
     Capture Length: 375 bytes
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d
     Destination: 00:50:fc:b1:ea:9d (10.1.6.5)
     Source: 00:00:24:c2:01:f4 (10.1.6.1)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
10.1.6.5 (10.1.6.5)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 361
     Identification: 0xd96d (55661)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 127
     Protocol: UDP (0x11)
     Header checksum: 0x31e8 (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 10.1.6.5 (10.1.6.5)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 (1208)
     Source port: 1571 (1571)
     Destination port: 1208 (1208)
     Length: 341
     Checksum: 0xbde1 (correct)
Session Initiation Protocol
     Request-Line: BYE sip:10.1.6.5:60324 SIP/2.0
         Method: BYE
         Resent Packet: True
         Suspected resend of frame: 2978
     Message Header
         Via: SIP/2.0/UDP 202.125.84.171:1571
         Max-Forwards: 70
         From: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP from address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         To: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP to address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5
         CSeq: 1 BYE
         User-Agent: RTC/1.2
         Content-Length: 0

No.     Time        Source                Destination           Protocol Info
    2995 
79.313436   10.1.6.5              202.125.84.171        SIP      Status: 200 OK

Frame 2995 (341 bytes on wire, 341 bytes captured)
     Arrival Time: Dec 14, 2004 11:36:11.500394000
     Time delta from previous packet: 0.524303000 seconds
     Time since reference or first frame: 79.313436000 seconds
     Frame Number: 2995
     Packet Length: 341 bytes
     Capture Length: 341 bytes
Ethernet II, Src: 00:50:fc:b1:ea:9d, Dst: 00:00:24:c2:01:f4
     Destination: 00:00:24:c2:01:f4 (10.1.6.1)
     Source: 00:50:fc:b1:ea:9d (10.1.6.5)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 10.1.6.5 (10.1.6.5), Dst Addr: 202.125.84.171 
(202.125.84.171)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 327
     Identification: 0xdf2a (57130)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x2b4d (correct)
     Source: 10.1.6.5 (10.1.6.5)
     Destination: 202.125.84.171 (202.125.84.171)
User Datagram Protocol, Src Port: 1208 (1208), Dst Port: 1571 (1571)
     Source port: 1208 (1208)
     Destination port: 1571 (1571)
     Length: 307
     Checksum: 0x5406 (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 200 OK
         Status-Code: 200
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 202.125.84.171:1571
         From: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP from address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         To: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP to address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5
         CSeq: 1 BYE
         User-Agent: RTC/1.2
         Content-Length: 0


Capture At the External Machine (Host 2)

No.     Time        Source                Destination           Protocol Info
     109 
31.434557   202.125.84.170        202.125.84.171        SIP/SDP  Request: 
INVITE sip:user@202.125.84.171:1571, with session description

Frame 109 (1112 bytes on wire, 1112 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:19.153166000
     Time delta from previous packet: 31.434557000 seconds
     Time since reference or first frame: 31.434557000 seconds
     Frame Number: 109
     Packet Length: 1112 bytes
     Capture Length: 1112 bytes
Ethernet II, Src: 00:00:24:c2:01:f5, Dst: 00:40:f4:3d:66:5f
     Destination: 00:40:f4:3d:66:5f (202.125.84.171)
     Source: 00:00:24:c2:01:f5 (202.125.84.170)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.170 (202.125.84.170), Dst Addr: 
202.125.84.171 (202.125.84.171)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 1098
     Identification: 0xd3d4 (54228)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 127
     Protocol: UDP (0x11)
     Header checksum: 0x257e (correct)
     Source: 202.125.84.170 (202.125.84.170)
     Destination: 202.125.84.171 (202.125.84.171)
User Datagram Protocol, Src Port: 60323 (60323), Dst Port: 1571 (1571)
     Source port: 60323 (60323)
     Destination port: 1571 (1571)
     Length: 1078
     Checksum: 0x899c (correct)
Session Initiation Protocol
     Request-Line: INVITE sip:user@202.125.84.171:1571 SIP/2.0
         Method: INVITE
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         Max-Forwards: 70
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>
             SIP to address: sip:user@202.125.84.171
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 INVITE
         Contact: <sip:202.125.84.170:60324>
         User-Agent: RTC/1.2
         Content-Type: application/sdp
         Content-Length: 681
     Message body
         Session Description Protocol
             Session Description Protocol Version (v): 0
             Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.170
                 Owner Username: -
                 Session ID: 0
                 Session Version: 0
                 Owner Network Type: IN
                 Owner Address Type: IP4
                 Owner Address: 202.125.84.170
             Session Name (s): session
             Connection Information (c): IN IP4 202.125.84.170
                 Connection Network Type: IN
                 Connection Address Type: IP4
                 Connection Address: 202.125.84.170
             Bandwidth Information (b): CT:1000
                 Bandwidth Modifier: CT
                 Bandwidth Value: 1000
             Time Description, active time (t): 0 0
                 Session Start Time: 0
                 Session Stop Time: 0
             Media Description, name and address (m): audio 60326 RTP/AVP 
97 111 112 6 0 8 4 5 3 101
                 Media Type: audio
                 Media Port: 60326
                 Media Proto: RTP/AVP
                 Media Format: 97
                 Media Format: 111
                 Media Format: 112
                 Media Format: DVI4 16000 samples/s
                 Media Format: ITU-T G.711 PCMU
                 Media Format: ITU-T G.711 PCMA
                 Media Format: ITU-T G.723
                 Media Format: DVI4 8000 samples/s
                 Media Format: GSM 06.10
                 Media Format: 101
             Encryption Key (k): 
base64:aINkrSXVFlOw/LgTKp5bHe1D1a/vQi7wV59gwbXEtRY
                 Key Type: base64
                 Key Data: aINkrSXVFlOw/LgTKp5bHe1D1a/vQi7wV59gwbXEtRY
             Media Attribute (a): rtpmap:97 red/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 97 red/8000
             Media Attribute (a): rtpmap:111 SIREN/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 111 SIREN/16000
             Media Attribute (a): fmtp:111 bitrate=16000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 111 bitrate=16000
             Media Attribute (a): rtpmap:112 G7221/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 112 G7221/16000
             Media Attribute (a): fmtp:112 bitrate=24000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 112 bitrate=24000
             Media Attribute (a): rtpmap:6 DVI4/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 6 DVI4/16000
             Media Attribute (a): rtpmap:0 PCMU/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 0 PCMU/8000
             Media Attribute (a): rtpmap:8 PCMA/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 8 PCMA/8000
             Media Attribute (a): rtpmap:4 G723/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 4 G723/8000
             Media Attribute (a): rtpmap:5 DVI4/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 5 DVI4/8000
             Media Attribute (a): rtpmap:3 GSM/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 3 GSM/8000
             Media Attribute (a): rtpmap:101 telephone-event/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 101 telephone-event/8000
             Media Attribute (a): fmtp:101 0-16
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 101 0-16
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional
             Media Description, name and address (m): video 60328 RTP/AVP 34 31
                 Media Type: video
                 Media Port: 60328
                 Media Proto: RTP/AVP
                 Media Format: ITU-T H.263
                 Media Format: ITU-T H.261
             Encryption Key (k): 
base64:9X9PloS9X/sgFGWluGGzdFVMn9iEMyaOMVKenrIlfYw
                 Key Type: base64
                 Key Data: 9X9PloS9X/sgFGWluGGzdFVMn9iEMyaOMVKenrIlfYw
             Media Attribute (a): rtpmap:34 H263/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 34 H263/90000
             Media Attribute (a): rtpmap:31 H261/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 31 H261/90000
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional

No.     Time        Source                Destination           Protocol Info
     110 
31.440348   202.125.84.171        202.125.84.170        SIP      Status: 
100 Trying

Frame 110 (355 bytes on wire, 355 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:19.158957000
     Time delta from previous packet: 0.005791000 seconds
     Time since reference or first frame: 31.440348000 seconds
     Frame Number: 110
     Packet Length: 355 bytes
     Capture Length: 355 bytes
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5
     Destination: 00:00:24:c2:01:f5 (202.125.84.170)
     Source: 00:40:f4:3d:66:5f (202.125.84.171)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
202.125.84.170 (202.125.84.170)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 341
     Identification: 0xd91e (55582)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x2229 (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 202.125.84.170 (202.125.84.170)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324 (60324)
     Source port: 1571 (1571)
     Destination port: 60324 (60324)
     Length: 321
     Checksum: 0x2dd3 (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 100 Trying
         Status-Code: 100
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 INVITE
         User-Agent: RTC/1.2
         Content-Length: 0

No.     Time        Source                Destination           Protocol Info
     111 
31.440840   202.125.84.171        202.125.84.170        SIP      Status: 
180 Ringing

Frame 111 (356 bytes on wire, 356 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:19.159449000
     Time delta from previous packet: 0.000492000 seconds
     Time since reference or first frame: 31.440840000 seconds
     Frame Number: 111
     Packet Length: 356 bytes
     Capture Length: 356 bytes
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5
     Destination: 00:00:24:c2:01:f5 (202.125.84.170)
     Source: 00:40:f4:3d:66:5f (202.125.84.171)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
202.125.84.170 (202.125.84.170)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 342
     Identification: 0xd91f (55583)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x2227 (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 202.125.84.170 (202.125.84.170)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324 (60324)
     Source port: 1571 (1571)
     Destination port: 60324 (60324)
     Length: 322
     Checksum: 0xaef6 (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 180 Ringing
         Status-Code: 180
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 INVITE
         User-Agent: RTC/1.2
         Content-Length: 0

No.     Time        Source                Destination           Protocol Info
     113 
31.782481   202.125.84.171        202.125.84.170        SIP/SDP  Status: 
200 OK, with session description

Frame 113 (1099 bytes on wire, 1099 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:19.501090000
     Time delta from previous packet: 0.341641000 seconds
     Time since reference or first frame: 31.782481000 seconds
     Frame Number: 113
     Packet Length: 1099 bytes
     Capture Length: 1099 bytes
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5
     Destination: 00:00:24:c2:01:f5 (202.125.84.170)
     Source: 00:40:f4:3d:66:5f (202.125.84.171)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
202.125.84.170 (202.125.84.170)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 1085
     Identification: 0xd920 (55584)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x1f3f (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 202.125.84.170 (202.125.84.170)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324 (60324)
     Source port: 1571 (1571)
     Destination port: 60324 (60324)
     Length: 1065
     Checksum: 0x9693 (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 200 OK
         Status-Code: 200
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 INVITE
         Contact: <sip:202.125.84.171:1571>
         User-Agent: RTC/1.2
         Content-Type: application/sdp
         Content-Length: 679
     Message body
         Session Description Protocol
             Session Description Protocol Version (v): 0
             Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171
                 Owner Username: -
                 Session ID: 0
                 Session Version: 0
                 Owner Network Type: IN
                 Owner Address Type: IP4
                 Owner Address: 202.125.84.171
             Session Name (s): session
             Connection Information (c): IN IP4 202.125.84.171
                 Connection Network Type: IN
                 Connection Address Type: IP4
                 Connection Address: 202.125.84.171
             Bandwidth Information (b): CT:1000
                 Bandwidth Modifier: CT
                 Bandwidth Value: 1000
             Time Description, active time (t): 0 0
                 Session Start Time: 0
                 Session Stop Time: 0
             Media Description, name and address (m): audio 1572 RTP/AVP 97 
111 112 6 0 8 4 5 3 101
                 Media Type: audio
                 Media Port: 1572
                 Media Proto: RTP/AVP
                 Media Format: 97
                 Media Format: 111
                 Media Format: 112
                 Media Format: DVI4 16000 samples/s
                 Media Format: ITU-T G.711 PCMU
                 Media Format: ITU-T G.711 PCMA
                 Media Format: ITU-T G.723
                 Media Format: DVI4 8000 samples/s
                 Media Format: GSM 06.10
                 Media Format: 101
             Encryption Key (k): 
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
                 Key Type: base64
                 Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
             Media Attribute (a): rtpmap:97 red/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 97 red/8000
             Media Attribute (a): rtpmap:111 SIREN/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 111 SIREN/16000
             Media Attribute (a): fmtp:111 bitrate=16000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 111 bitrate=16000
             Media Attribute (a): rtpmap:112 G7221/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 112 G7221/16000
             Media Attribute (a): fmtp:112 bitrate=24000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 112 bitrate=24000
             Media Attribute (a): rtpmap:6 DVI4/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 6 DVI4/16000
             Media Attribute (a): rtpmap:0 PCMU/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 0 PCMU/8000
             Media Attribute (a): rtpmap:8 PCMA/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 8 PCMA/8000
             Media Attribute (a): rtpmap:4 G723/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 4 G723/8000
             Media Attribute (a): rtpmap:5 DVI4/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 5 DVI4/8000
             Media Attribute (a): rtpmap:3 GSM/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 3 GSM/8000
             Media Attribute (a): rtpmap:101 telephone-event/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 101 telephone-event/8000
             Media Attribute (a): fmtp:101 0-16
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 101 0-16
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional
             Media Description, name and address (m): video 1574 RTP/AVP 34 31
                 Media Type: video
                 Media Port: 1574
                 Media Proto: RTP/AVP
                 Media Format: ITU-T H.263
                 Media Format: ITU-T H.261
             Encryption Key (k): 
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
                 Key Type: base64
                 Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
             Media Attribute (a): rtpmap:34 H263/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 34 H263/90000
             Media Attribute (a): rtpmap:31 H261/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 31 H261/90000
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional

No.     Time        Source                Destination           Protocol Info
     115 
32.271844   202.125.84.171        202.125.84.170        SIP/SDP  Status: 
200 OK, with session description

Frame 115 (1099 bytes on wire, 1099 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:19.990453000
     Time delta from previous packet: 0.489363000 seconds
     Time since reference or first frame: 32.271844000 seconds
     Frame Number: 115
     Packet Length: 1099 bytes
     Capture Length: 1099 bytes
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5
     Destination: 00:00:24:c2:01:f5 (202.125.84.170)
     Source: 00:40:f4:3d:66:5f (202.125.84.171)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
202.125.84.170 (202.125.84.170)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 1085
     Identification: 0xd921 (55585)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x1f3e (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 202.125.84.170 (202.125.84.170)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324 (60324)
     Source port: 1571 (1571)
     Destination port: 60324 (60324)
     Length: 1065
     Checksum: 0x9693 (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 200 OK
         Status-Code: 200
         Resent Packet: True
         Suspected resend of frame: 113
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 INVITE
         Contact: <sip:202.125.84.171:1571>
         User-Agent: RTC/1.2
         Content-Type: application/sdp
         Content-Length: 679
     Message body
         Session Description Protocol
             Session Description Protocol Version (v): 0
             Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171
                 Owner Username: -
                 Session ID: 0
                 Session Version: 0
                 Owner Network Type: IN
                 Owner Address Type: IP4
                 Owner Address: 202.125.84.171
             Session Name (s): session
             Connection Information (c): IN IP4 202.125.84.171
                 Connection Network Type: IN
                 Connection Address Type: IP4
                 Connection Address: 202.125.84.171
             Bandwidth Information (b): CT:1000
                 Bandwidth Modifier: CT
                 Bandwidth Value: 1000
             Time Description, active time (t): 0 0
                 Session Start Time: 0
                 Session Stop Time: 0
             Media Description, name and address (m): audio 1572 RTP/AVP 97 
111 112 6 0 8 4 5 3 101
                 Media Type: audio
                 Media Port: 1572
                 Media Proto: RTP/AVP
                 Media Format: 97
                 Media Format: 111
                 Media Format: 112
                 Media Format: DVI4 16000 samples/s
                 Media Format: ITU-T G.711 PCMU
                 Media Format: ITU-T G.711 PCMA
                 Media Format: ITU-T G.723
                 Media Format: DVI4 8000 samples/s
                 Media Format: GSM 06.10
                 Media Format: 101
             Encryption Key (k): 
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
                 Key Type: base64
                 Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
             Media Attribute (a): rtpmap:97 red/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 97 red/8000
             Media Attribute (a): rtpmap:111 SIREN/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 111 SIREN/16000
             Media Attribute (a): fmtp:111 bitrate=16000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 111 bitrate=16000
             Media Attribute (a): rtpmap:112 G7221/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 112 G7221/16000
             Media Attribute (a): fmtp:112 bitrate=24000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 112 bitrate=24000
             Media Attribute (a): rtpmap:6 DVI4/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 6 DVI4/16000
             Media Attribute (a): rtpmap:0 PCMU/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 0 PCMU/8000
             Media Attribute (a): rtpmap:8 PCMA/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 8 PCMA/8000
             Media Attribute (a): rtpmap:4 G723/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 4 G723/8000
             Media Attribute (a): rtpmap:5 DVI4/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 5 DVI4/8000
             Media Attribute (a): rtpmap:3 GSM/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 3 GSM/8000
             Media Attribute (a): rtpmap:101 telephone-event/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 101 telephone-event/8000
             Media Attribute (a): fmtp:101 0-16
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 101 0-16
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional
             Media Description, name and address (m): video 1574 RTP/AVP 34 31
                 Media Type: video
                 Media Port: 1574
                 Media Proto: RTP/AVP
                 Media Format: ITU-T H.263
                 Media Format: ITU-T H.261
             Encryption Key (k): 
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
                 Key Type: base64
                 Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
             Media Attribute (a): rtpmap:34 H263/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 34 H263/90000
             Media Attribute (a): rtpmap:31 H261/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 31 H261/90000
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional

No.     Time        Source                Destination           Protocol Info
     164 
33.272848   202.125.84.171        202.125.84.170        SIP/SDP  Status: 
200 OK, with session description

Frame 164 (1099 bytes on wire, 1099 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:20.991457000
     Time delta from previous packet: 1.001004000 seconds
     Time since reference or first frame: 33.272848000 seconds
     Frame Number: 164
     Packet Length: 1099 bytes
     Capture Length: 1099 bytes
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5
     Destination: 00:00:24:c2:01:f5 (202.125.84.170)
     Source: 00:40:f4:3d:66:5f (202.125.84.171)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
202.125.84.170 (202.125.84.170)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 1085
     Identification: 0xd923 (55587)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x1f3c (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 202.125.84.170 (202.125.84.170)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324 (60324)
     Source port: 1571 (1571)
     Destination port: 60324 (60324)
     Length: 1065
     Checksum: 0x9693 (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 200 OK
         Status-Code: 200
         Resent Packet: True
         Suspected resend of frame: 113
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 INVITE
         Contact: <sip:202.125.84.171:1571>
         User-Agent: RTC/1.2
         Content-Type: application/sdp
         Content-Length: 679
     Message body
         Session Description Protocol
             Session Description Protocol Version (v): 0
             Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171
                 Owner Username: -
                 Session ID: 0
                 Session Version: 0
                 Owner Network Type: IN
                 Owner Address Type: IP4
                 Owner Address: 202.125.84.171
             Session Name (s): session
             Connection Information (c): IN IP4 202.125.84.171
                 Connection Network Type: IN
                 Connection Address Type: IP4
                 Connection Address: 202.125.84.171
             Bandwidth Information (b): CT:1000
                 Bandwidth Modifier: CT
                 Bandwidth Value: 1000
             Time Description, active time (t): 0 0
                 Session Start Time: 0
                 Session Stop Time: 0
             Media Description, name and address (m): audio 1572 RTP/AVP 97 
111 112 6 0 8 4 5 3 101
                 Media Type: audio
                 Media Port: 1572
                 Media Proto: RTP/AVP
                 Media Format: 97
                 Media Format: 111
                 Media Format: 112
                 Media Format: DVI4 16000 samples/s
                 Media Format: ITU-T G.711 PCMU
                 Media Format: ITU-T G.711 PCMA
                 Media Format: ITU-T G.723
                 Media Format: DVI4 8000 samples/s
                 Media Format: GSM 06.10
                 Media Format: 101
             Encryption Key (k): 
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
                 Key Type: base64
                 Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
             Media Attribute (a): rtpmap:97 red/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 97 red/8000
             Media Attribute (a): rtpmap:111 SIREN/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 111 SIREN/16000
             Media Attribute (a): fmtp:111 bitrate=16000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 111 bitrate=16000
             Media Attribute (a): rtpmap:112 G7221/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 112 G7221/16000
             Media Attribute (a): fmtp:112 bitrate=24000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 112 bitrate=24000
             Media Attribute (a): rtpmap:6 DVI4/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 6 DVI4/16000
             Media Attribute (a): rtpmap:0 PCMU/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 0 PCMU/8000
             Media Attribute (a): rtpmap:8 PCMA/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 8 PCMA/8000
             Media Attribute (a): rtpmap:4 G723/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 4 G723/8000
             Media Attribute (a): rtpmap:5 DVI4/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 5 DVI4/8000
             Media Attribute (a): rtpmap:3 GSM/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 3 GSM/8000
             Media Attribute (a): rtpmap:101 telephone-event/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 101 telephone-event/8000
             Media Attribute (a): fmtp:101 0-16
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 101 0-16
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional
             Media Description, name and address (m): video 1574 RTP/AVP 34 31
                 Media Type: video
                 Media Port: 1574
                 Media Proto: RTP/AVP
                 Media Format: ITU-T H.263
                 Media Format: ITU-T H.261
             Encryption Key (k): 
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
                 Key Type: base64
                 Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
             Media Attribute (a): rtpmap:34 H263/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 34 H263/90000
             Media Attribute (a): rtpmap:31 H261/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 31 H261/90000
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional

No.     Time        Source                Destination           Protocol Info
     211 
34.117383   202.125.84.170        202.125.84.171        SIP      Request: 
ACK sip:202.125.84.171:1571

Frame 211 (387 bytes on wire, 387 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:21.835992000
     Time delta from previous packet: 0.844535000 seconds
     Time since reference or first frame: 34.117383000 seconds
     Frame Number: 211
     Packet Length: 387 bytes
     Capture Length: 387 bytes
Ethernet II, Src: 00:00:24:c2:01:f5, Dst: 00:40:f4:3d:66:5f
     Destination: 00:40:f4:3d:66:5f (202.125.84.171)
     Source: 00:00:24:c2:01:f5 (202.125.84.170)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.170 (202.125.84.170), Dst Addr: 
202.125.84.171 (202.125.84.171)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 373
     Identification: 0xd431 (54321)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 127
     Protocol: UDP (0x11)
     Header checksum: 0x27f6 (correct)
     Source: 202.125.84.170 (202.125.84.170)
     Destination: 202.125.84.171 (202.125.84.171)
User Datagram Protocol, Src Port: 60323 (60323), Dst Port: 1571 (1571)
     Source port: 60323 (60323)
     Destination port: 1571 (1571)
     Length: 353
     Checksum: 0xa19b (correct)
Session Initiation Protocol
     Request-Line: ACK sip:202.125.84.171:1571 SIP/2.0
         Method: ACK
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         Max-Forwards: 70
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 ACK
         User-Agent: RTC/1.2
         Content-Length: 0

No.     Time        Source                Destination           Protocol Info
     221 
34.247583   202.125.84.170        202.125.84.171        SIP      Request: 
ACK sip:202.125.84.171:1571

Frame 221 (387 bytes on wire, 387 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:21.966192000
     Time delta from previous packet: 0.130200000 seconds
     Time since reference or first frame: 34.247583000 seconds
     Frame Number: 221
     Packet Length: 387 bytes
     Capture Length: 387 bytes
Ethernet II, Src: 00:00:24:c2:01:f5, Dst: 00:40:f4:3d:66:5f
     Destination: 00:40:f4:3d:66:5f (202.125.84.171)
     Source: 00:00:24:c2:01:f5 (202.125.84.170)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.170 (202.125.84.170), Dst Addr: 
202.125.84.171 (202.125.84.171)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 373
     Identification: 0xd43a (54330)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 127
     Protocol: UDP (0x11)
     Header checksum: 0x27ed (correct)
     Source: 202.125.84.170 (202.125.84.170)
     Destination: 202.125.84.171 (202.125.84.171)
User Datagram Protocol, Src Port: 60323 (60323), Dst Port: 1571 (1571)
     Source port: 60323 (60323)
     Destination port: 1571 (1571)
     Length: 353
     Checksum: 0xa19b (correct)
Session Initiation Protocol
     Request-Line: ACK sip:202.125.84.171:1571 SIP/2.0
         Method: ACK
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         Max-Forwards: 70
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 ACK
         User-Agent: RTC/1.2
         Content-Length: 0

No.     Time        Source                Destination           Protocol Info
     223 
34.277092   202.125.84.170        202.125.84.171        SIP      Request: 
ACK sip:202.125.84.171:1571

Frame 223 (387 bytes on wire, 387 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:21.995701000
     Time delta from previous packet: 0.029509000 seconds
     Time since reference or first frame: 34.277092000 seconds
     Frame Number: 223
     Packet Length: 387 bytes
     Capture Length: 387 bytes
Ethernet II, Src: 00:00:24:c2:01:f5, Dst: 00:40:f4:3d:66:5f
     Destination: 00:40:f4:3d:66:5f (202.125.84.171)
     Source: 00:00:24:c2:01:f5 (202.125.84.170)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.170 (202.125.84.170), Dst Addr: 
202.125.84.171 (202.125.84.171)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 373
     Identification: 0xd43c (54332)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 127
     Protocol: UDP (0x11)
     Header checksum: 0x27eb (correct)
     Source: 202.125.84.170 (202.125.84.170)
     Destination: 202.125.84.171 (202.125.84.171)
User Datagram Protocol, Src Port: 60323 (60323), Dst Port: 1571 (1571)
     Source port: 60323 (60323)
     Destination port: 1571 (1571)
     Length: 353
     Checksum: 0xa19b (correct)
Session Initiation Protocol
     Request-Line: ACK sip:202.125.84.171:1571 SIP/2.0
         Method: ACK
         Resent Packet: False
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         Max-Forwards: 70
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 ACK
         User-Agent: RTC/1.2
         Content-Length: 0

No.     Time        Source                Destination           Protocol Info
     262 
35.272771   202.125.84.171        202.125.84.170        SIP/SDP  Status: 
200 OK, with session description

Frame 262 (1099 bytes on wire, 1099 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:22.991380000
     Time delta from previous packet: 0.995679000 seconds
     Time since reference or first frame: 35.272771000 seconds
     Frame Number: 262
     Packet Length: 1099 bytes
     Capture Length: 1099 bytes
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5
     Destination: 00:00:24:c2:01:f5 (202.125.84.170)
     Source: 00:40:f4:3d:66:5f (202.125.84.171)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
202.125.84.170 (202.125.84.170)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 1085
     Identification: 0xd926 (55590)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x1f39 (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 202.125.84.170 (202.125.84.170)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324 (60324)
     Source port: 1571 (1571)
     Destination port: 60324 (60324)
     Length: 1065
     Checksum: 0x9693 (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 200 OK
         Status-Code: 200
         Resent Packet: True
         Suspected resend of frame: 113
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 INVITE
         Contact: <sip:202.125.84.171:1571>
         User-Agent: RTC/1.2
         Content-Type: application/sdp
         Content-Length: 679
     Message body
         Session Description Protocol
             Session Description Protocol Version (v): 0
             Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171
                 Owner Username: -
                 Session ID: 0
                 Session Version: 0
                 Owner Network Type: IN
                 Owner Address Type: IP4
                 Owner Address: 202.125.84.171
             Session Name (s): session
             Connection Information (c): IN IP4 202.125.84.171
                 Connection Network Type: IN
                 Connection Address Type: IP4
                 Connection Address: 202.125.84.171
             Bandwidth Information (b): CT:1000
                 Bandwidth Modifier: CT
                 Bandwidth Value: 1000
             Time Description, active time (t): 0 0
                 Session Start Time: 0
                 Session Stop Time: 0
             Media Description, name and address (m): audio 1572 RTP/AVP 97 
111 112 6 0 8 4 5 3 101
                 Media Type: audio
                 Media Port: 1572
                 Media Proto: RTP/AVP
                 Media Format: 97
                 Media Format: 111
                 Media Format: 112
                 Media Format: DVI4 16000 samples/s
                 Media Format: ITU-T G.711 PCMU
                 Media Format: ITU-T G.711 PCMA
                 Media Format: ITU-T G.723
                 Media Format: DVI4 8000 samples/s
                 Media Format: GSM 06.10
                 Media Format: 101
             Encryption Key (k): 
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
                 Key Type: base64
                 Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
             Media Attribute (a): rtpmap:97 red/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 97 red/8000
             Media Attribute (a): rtpmap:111 SIREN/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 111 SIREN/16000
             Media Attribute (a): fmtp:111 bitrate=16000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 111 bitrate=16000
             Media Attribute (a): rtpmap:112 G7221/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 112 G7221/16000
             Media Attribute (a): fmtp:112 bitrate=24000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 112 bitrate=24000
             Media Attribute (a): rtpmap:6 DVI4/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 6 DVI4/16000
             Media Attribute (a): rtpmap:0 PCMU/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 0 PCMU/8000
             Media Attribute (a): rtpmap:8 PCMA/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 8 PCMA/8000
             Media Attribute (a): rtpmap:4 G723/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 4 G723/8000
             Media Attribute (a): rtpmap:5 DVI4/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 5 DVI4/8000
             Media Attribute (a): rtpmap:3 GSM/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 3 GSM/8000
             Media Attribute (a): rtpmap:101 telephone-event/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 101 telephone-event/8000
             Media Attribute (a): fmtp:101 0-16
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 101 0-16
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional
             Media Description, name and address (m): video 1574 RTP/AVP 34 31
                 Media Type: video
                 Media Port: 1574
                 Media Proto: RTP/AVP
                 Media Format: ITU-T H.263
                 Media Format: ITU-T H.261
             Encryption Key (k): 
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
                 Key Type: base64
                 Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
             Media Attribute (a): rtpmap:34 H263/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 34 H263/90000
             Media Attribute (a): rtpmap:31 H261/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 31 H261/90000
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional

No.     Time        Source                Destination           Protocol Info
     416 
39.270667   202.125.84.171        202.125.84.170        SIP/SDP  Status: 
200 OK, with session description

Frame 416 (1099 bytes on wire, 1099 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:26.989276000
     Time delta from previous packet: 3.997896000 seconds
     Time since reference or first frame: 39.270667000 seconds
     Frame Number: 416
     Packet Length: 1099 bytes
     Capture Length: 1099 bytes
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5
     Destination: 00:00:24:c2:01:f5 (202.125.84.170)
     Source: 00:40:f4:3d:66:5f (202.125.84.171)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
202.125.84.170 (202.125.84.170)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 1085
     Identification: 0xd92a (55594)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x1f35 (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 202.125.84.170 (202.125.84.170)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324 (60324)
     Source port: 1571 (1571)
     Destination port: 60324 (60324)
     Length: 1065
     Checksum: 0x9693 (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 200 OK
         Status-Code: 200
         Resent Packet: True
         Suspected resend of frame: 113
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 INVITE
         Contact: <sip:202.125.84.171:1571>
         User-Agent: RTC/1.2
         Content-Type: application/sdp
         Content-Length: 679
     Message body
         Session Description Protocol
             Session Description Protocol Version (v): 0
             Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171
                 Owner Username: -
                 Session ID: 0
                 Session Version: 0
                 Owner Network Type: IN
                 Owner Address Type: IP4
                 Owner Address: 202.125.84.171
             Session Name (s): session
             Connection Information (c): IN IP4 202.125.84.171
                 Connection Network Type: IN
                 Connection Address Type: IP4
                 Connection Address: 202.125.84.171
             Bandwidth Information (b): CT:1000
                 Bandwidth Modifier: CT
                 Bandwidth Value: 1000
             Time Description, active time (t): 0 0
                 Session Start Time: 0
                 Session Stop Time: 0
             Media Description, name and address (m): audio 1572 RTP/AVP 97 
111 112 6 0 8 4 5 3 101
                 Media Type: audio
                 Media Port: 1572
                 Media Proto: RTP/AVP
                 Media Format: 97
                 Media Format: 111
                 Media Format: 112
                 Media Format: DVI4 16000 samples/s
                 Media Format: ITU-T G.711 PCMU
                 Media Format: ITU-T G.711 PCMA
                 Media Format: ITU-T G.723
                 Media Format: DVI4 8000 samples/s
                 Media Format: GSM 06.10
                 Media Format: 101
             Encryption Key (k): 
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
                 Key Type: base64
                 Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
             Media Attribute (a): rtpmap:97 red/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 97 red/8000
             Media Attribute (a): rtpmap:111 SIREN/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 111 SIREN/16000
             Media Attribute (a): fmtp:111 bitrate=16000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 111 bitrate=16000
             Media Attribute (a): rtpmap:112 G7221/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 112 G7221/16000
             Media Attribute (a): fmtp:112 bitrate=24000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 112 bitrate=24000
             Media Attribute (a): rtpmap:6 DVI4/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 6 DVI4/16000
             Media Attribute (a): rtpmap:0 PCMU/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 0 PCMU/8000
             Media Attribute (a): rtpmap:8 PCMA/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 8 PCMA/8000
             Media Attribute (a): rtpmap:4 G723/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 4 G723/8000
             Media Attribute (a): rtpmap:5 DVI4/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 5 DVI4/8000
             Media Attribute (a): rtpmap:3 GSM/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 3 GSM/8000
             Media Attribute (a): rtpmap:101 telephone-event/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 101 telephone-event/8000
             Media Attribute (a): fmtp:101 0-16
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 101 0-16
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional
             Media Description, name and address (m): video 1574 RTP/AVP 34 31
                 Media Type: video
                 Media Port: 1574
                 Media Proto: RTP/AVP
                 Media Format: ITU-T H.263
                 Media Format: ITU-T H.261
             Encryption Key (k): 
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
                 Key Type: base64
                 Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
             Media Attribute (a): rtpmap:34 H263/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 34 H263/90000
             Media Attribute (a): rtpmap:31 H261/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 31 H261/90000
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional

No.     Time        Source                Destination           Protocol Info
     586 
47.270357   202.125.84.171        202.125.84.170        SIP/SDP  Status: 
200 OK, with session description

Frame 586 (1099 bytes on wire, 1099 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:34.988966000
     Time delta from previous packet: 7.999690000 seconds
     Time since reference or first frame: 47.270357000 seconds
     Frame Number: 586
     Packet Length: 1099 bytes
     Capture Length: 1099 bytes
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5
     Destination: 00:00:24:c2:01:f5 (202.125.84.170)
     Source: 00:40:f4:3d:66:5f (202.125.84.171)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
202.125.84.170 (202.125.84.170)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 1085
     Identification: 0xd92e (55598)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x1f31 (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 202.125.84.170 (202.125.84.170)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324 (60324)
     Source port: 1571 (1571)
     Destination port: 60324 (60324)
     Length: 1065
     Checksum: 0x9693 (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 200 OK
         Status-Code: 200
         Resent Packet: True
         Suspected resend of frame: 113
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 INVITE
         Contact: <sip:202.125.84.171:1571>
         User-Agent: RTC/1.2
         Content-Type: application/sdp
         Content-Length: 679
     Message body
         Session Description Protocol
             Session Description Protocol Version (v): 0
             Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171
                 Owner Username: -
                 Session ID: 0
                 Session Version: 0
                 Owner Network Type: IN
                 Owner Address Type: IP4
                 Owner Address: 202.125.84.171
             Session Name (s): session
             Connection Information (c): IN IP4 202.125.84.171
                 Connection Network Type: IN
                 Connection Address Type: IP4
                 Connection Address: 202.125.84.171
             Bandwidth Information (b): CT:1000
                 Bandwidth Modifier: CT
                 Bandwidth Value: 1000
             Time Description, active time (t): 0 0
                 Session Start Time: 0
                 Session Stop Time: 0
             Media Description, name and address (m): audio 1572 RTP/AVP 97 
111 112 6 0 8 4 5 3 101
                 Media Type: audio
                 Media Port: 1572
                 Media Proto: RTP/AVP
                 Media Format: 97
                 Media Format: 111
                 Media Format: 112
                 Media Format: DVI4 16000 samples/s
                 Media Format: ITU-T G.711 PCMU
                 Media Format: ITU-T G.711 PCMA
                 Media Format: ITU-T G.723
                 Media Format: DVI4 8000 samples/s
                 Media Format: GSM 06.10
                 Media Format: 101
             Encryption Key (k): 
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
                 Key Type: base64
                 Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
             Media Attribute (a): rtpmap:97 red/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 97 red/8000
             Media Attribute (a): rtpmap:111 SIREN/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 111 SIREN/16000
             Media Attribute (a): fmtp:111 bitrate=16000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 111 bitrate=16000
             Media Attribute (a): rtpmap:112 G7221/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 112 G7221/16000
             Media Attribute (a): fmtp:112 bitrate=24000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 112 bitrate=24000
             Media Attribute (a): rtpmap:6 DVI4/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 6 DVI4/16000
             Media Attribute (a): rtpmap:0 PCMU/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 0 PCMU/8000
             Media Attribute (a): rtpmap:8 PCMA/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 8 PCMA/8000
             Media Attribute (a): rtpmap:4 G723/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 4 G723/8000
             Media Attribute (a): rtpmap:5 DVI4/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 5 DVI4/8000
             Media Attribute (a): rtpmap:3 GSM/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 3 GSM/8000
             Media Attribute (a): rtpmap:101 telephone-event/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 101 telephone-event/8000
             Media Attribute (a): fmtp:101 0-16
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 101 0-16
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional
             Media Description, name and address (m): video 1574 RTP/AVP 34 31
                 Media Type: video
                 Media Port: 1574
                 Media Proto: RTP/AVP
                 Media Format: ITU-T H.263
                 Media Format: ITU-T H.261
             Encryption Key (k): 
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
                 Key Type: base64
                 Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
             Media Attribute (a): rtpmap:34 H263/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 34 H263/90000
             Media Attribute (a): rtpmap:31 H261/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 31 H261/90000
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional

No.     Time        Source                Destination           Protocol Info
    1275 
63.270736   202.125.84.171        202.125.84.170        SIP/SDP  Status: 
200 OK, with session description

Frame 1275 (1099 bytes on wire, 1099 bytes captured)
     Arrival Time: Dec 14, 2004 11:35:50.989345000
     Time delta from previous packet: 16.000379000 seconds
     Time since reference or first frame: 63.270736000 seconds
     Frame Number: 1275
     Packet Length: 1099 bytes
     Capture Length: 1099 bytes
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5
     Destination: 00:00:24:c2:01:f5 (202.125.84.170)
     Source: 00:40:f4:3d:66:5f (202.125.84.171)
     Type: IP (0x0800)
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr: 
202.125.84.170 (202.125.84.170)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 1085
     Identification: 0xd945 (55621)
     Flags: 0x00
         0... = Reserved bit: Not set
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0x1f1a (correct)
     Source: 202.125.84.171 (202.125.84.171)
     Destination: 202.125.84.170 (202.125.84.170)
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324 (60324)
     Source port: 1571 (1571)
     Destination port: 60324 (60324)
     Length: 1065
     Checksum: 0x9693 (correct)
Session Initiation Protocol
     Status-Line: SIP/2.0 200 OK
         Status-Code: 200
         Resent Packet: True
         Suspected resend of frame: 113
     Message Header
         Via: SIP/2.0/UDP 202.125.84.170:60324
         From: "intoalg2" <sip:intoalg2>;tag=3a35760de42649f28e341a80a9edf4f7
             SIP Display info: "intoalg2"
             SIP from address: sip:intoalg2
             SIP tag: 3a35760de42649f28e341a80a9edf4f7
         To: <sip:user@202.125.84.171>;tag=f025608bd41248b48746df9fd86f6fc9
             SIP to address: sip:user@202.125.84.171
             SIP tag: f025608bd41248b48746df9fd86f6fc9
         Call-ID: 04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170
         CSeq: 1 INVITE
         Contact: <sip:202.125.84.171:1571>
         User-Agent: RTC/1.2
         Content-Type: application/sdp
         Content-Length: 679
     Message body
         Session Description Protocol
             Session Description Protocol Version (v): 0
             Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171
                 Owner Username: -
                 Session ID: 0
                 Session Version: 0
                 Owner Network Type: IN
                 Owner Address Type: IP4
                 Owner Address: 202.125.84.171
             Session Name (s): session
             Connection Information (c): IN IP4 202.125.84.171
                 Connection Network Type: IN
                 Connection Address Type: IP4
                 Connection Address: 202.125.84.171
             Bandwidth Information (b): CT:1000
                 Bandwidth Modifier: CT
                 Bandwidth Value: 1000
             Time Description, active time (t): 0 0
                 Session Start Time: 0
                 Session Stop Time: 0
             Media Description, name and address (m): audio 1572 RTP/AVP 97 
111 112 6 0 8 4 5 3 101
                 Media Type: audio
                 Media Port: 1572
                 Media Proto: RTP/AVP
                 Media Format: 97
                 Media Format: 111
                 Media Format: 112
                 Media Format: DVI4 16000 samples/s
                 Media Format: ITU-T G.711 PCMU
                 Media Format: ITU-T G.711 PCMA
                 Media Format: ITU-T G.723
                 Media Format: DVI4 8000 samples/s
                 Media Format: GSM 06.10
                 Media Format: 101
             Encryption Key (k): 
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
                 Key Type: base64
                 Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE
             Media Attribute (a): rtpmap:97 red/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 97 red/8000
             Media Attribute (a): rtpmap:111 SIREN/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 111 SIREN/16000
             Media Attribute (a): fmtp:111 bitrate=16000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 111 bitrate=16000
             Media Attribute (a): rtpmap:112 G7221/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 112 G7221/16000
             Media Attribute (a): fmtp:112 bitrate=24000
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 112 bitrate=24000
             Media Attribute (a): rtpmap:6 DVI4/16000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 6 DVI4/16000
             Media Attribute (a): rtpmap:0 PCMU/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 0 PCMU/8000
             Media Attribute (a): rtpmap:8 PCMA/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 8 PCMA/8000
             Media Attribute (a): rtpmap:4 G723/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 4 G723/8000
             Media Attribute (a): rtpmap:5 DVI4/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 5 DVI4/8000
             Media Attribute (a): rtpmap:3 GSM/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 3 GSM/8000
             Media Attribute (a): rtpmap:101 telephone-event/8000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 101 telephone-event/8000
             Media Attribute (a): fmtp:101 0-16
                 Media Attribute Fieldname: fmtp
                 Media Attribute Value: 101 0-16
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional
             Media Description, name and address (m): video 1574 RTP/AVP 34 31
                 Media Type: video
                 Media Port: 1574
                 Media Proto: RTP/AVP
                 Media Format: ITU-T H.263
                 Media Format: ITU-T H.261
             Encryption Key (k): 
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
                 Key Type: base64
                 Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg
             Media Attribute (a): rtpmap:34 H263/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 34 H263/90000
             Media Attribute (a): rtpmap:31 H261/90000
                 Media Attribute Fieldname: rtpmap
                 Media Attribute Value: 31 H261/90000
             Media Attribute (a): encryption:optional
                 Media Attribute Fieldname: encryption
                 Media Attribute Value: optional


--=====================_6427312==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Hi All,<br><br>
I have a doubt regarding the processing of ACK&nbsp; by the UA. The UA ,
even after receving ACK from the other UA is still sending 200 OK's.
<br><br>
I am using the following configuration.<br><br>
Host1------------Firewall---------------------------Internet<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Host2<br><br>
I am using AOL instant messenger on both the hosts. I started video from
Host2 to Host1. As AOL video uses SIP for connection establishment, Host1
sends SIP INVITE to HOST2 and the following figure depicts the flow of
the packets between the two UA's.<br><br>
Host1--------------------------------------Host2<br>
INVITE----------------------&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;---------------------&nbsp; 100 Trying<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;---------------------&nbsp; 180 Ringing<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;---------------------- 200 OK<br>
ACK&nbsp;&nbsp;&nbsp; -----------------------&gt;<br><br>
After receiving the ACK, Host 2 is still sending 200 OK's . It is
happening often but not all the times.<br>
I have attached the capture of&nbsp; failure case. Could anyone please
help me in finding out why Host2 is sending 200 OK' s even after
receiving ACK.<br><br>
<br>
<b>Failure Case <br>
Capture At Internal Machine (HOST 1)<br>
</b><font face="Courier New, Courier">No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp;&nbsp; 68 14.197405&nbsp;&nbsp;
10.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP/SDP&nbsp;
Request: INVITE sip:user@202.125.84.171:1571, with session
description<br><br>
Frame 68 (1078 bytes on wire, 1078 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:06.384363000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 14.197405000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 14.197405000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 68<br>
&nbsp;&nbsp;&nbsp; Packet Length: 1078 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 1078 bytes<br>
Ethernet II, Src: 00:50:fc:b1:ea:9d, Dst: 00:00:24:c2:01:f4<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f4 (10.1.6.1)<br>
&nbsp;&nbsp;&nbsp; Source: 00:50:fc:b1:ea:9d (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 10.1.6.5 (10.1.6.5), Dst Addr:
202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 1064<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd3d4 (54228)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x33c2 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 10.1.6.5 (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.171 (202.125.84.171)<br>
User Datagram Protocol, Src Port: 1208 (1208), Dst Port: 1571 
(1571)<br>
&nbsp;&nbsp;&nbsp; Source port: 1208 (1208)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Length: 1044<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x69e1 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Request-Line: INVITE sip:user@202.125.84.171:1571
SIP/2.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Method: INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
10.1.6.5:1208<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Max-Forwards: 70<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact:
&lt;sip:10.1.6.5:1208&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type:
application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 667<br>
&nbsp;&nbsp;&nbsp; Message body<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Session Description
Protocol<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Description Protocol Version (v): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner/Creator, Session Id (o): - 0 0 IN IP4 10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Username: -<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session ID: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Version: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address: 10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Name (s): session<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Information (c): IN IP4 10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address: 10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Information (b): CT:1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Modifier: CT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Value: 1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time
Description, active time (t): 0 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Start Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Stop Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): audio 1211 RTP/AVP 97 111 112 6 0 8 4
5 3 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1211<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 97<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 111<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 112<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 16000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMU<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.723<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 8000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: GSM 06.10<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:aINkrSXVFlOw/LgTKp5bHe1D1a/vQi7wV59gwbXEtRY<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: aINkrSXVFlOw/LgTKp5bHe1D1a/vQi7wV59gwbXEtRY<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): video 1209 RTP/AVP 34 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: video<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1209<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.263<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.261<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:9X9PloS9X/sgFGWluGGzdFVMn9iEMyaOMVKenrIlfYw<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: 9X9PloS9X/sgFGWluGGzdFVMn9iEMyaOMVKenrIlfYw<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp;&nbsp; 69 14.208670&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
10.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status: 100 Trying<br><br>
Frame 69 (337 bytes on wire, 337 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:06.395628000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.011265000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 14.208670000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 69<br>
&nbsp;&nbsp;&nbsp; Packet Length: 337 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 337 bytes<br>
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d<br>
&nbsp;&nbsp;&nbsp; Destination: 00:50:fc:b1:ea:9d (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Source: 00:00:24:c2:01:f4 (10.1.6.1)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
10.1.6.5 (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 323<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd91e (55582)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 127<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x325d (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 10.1.6.5 (10.1.6.5)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 
(1208)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1208 (1208)<br>
&nbsp;&nbsp;&nbsp; Length: 303<br>
&nbsp;&nbsp;&nbsp; Checksum: 0xd0fb (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 100 Trying<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 100<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP 
10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp;&nbsp; 70 14.209958&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
10.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status: 180 Ringing<br><br>
Frame 70 (338 bytes on wire, 338 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:06.396916000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.001288000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 14.209958000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 70<br>
&nbsp;&nbsp;&nbsp; Packet Length: 338 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 338 bytes<br>
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d<br>
&nbsp;&nbsp;&nbsp; Destination: 00:50:fc:b1:ea:9d (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Source: 00:00:24:c2:01:f4 (10.1.6.1)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
10.1.6.5 (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 324<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd91f (55583)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 127<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x325b (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 10.1.6.5 (10.1.6.5)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 
(1208)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1208 (1208)<br>
&nbsp;&nbsp;&nbsp; Length: 304<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x9ad6 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 180 Ringing<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 180<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP 
10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp;&nbsp; 71 14.553022&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
10.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP/SDP&nbsp; Status: 200 OK, with session description<br><br>
Frame 71 (1081 bytes on wire, 1081 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:06.739980000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.343064000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 14.553022000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 71<br>
&nbsp;&nbsp;&nbsp; Packet Length: 1081 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 1081 bytes<br>
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d<br>
&nbsp;&nbsp;&nbsp; Destination: 00:50:fc:b1:ea:9d (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Source: 00:00:24:c2:01:f4 (10.1.6.1)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
10.1.6.5 (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 1067<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd920 (55584)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 127<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x2f73 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 10.1.6.5 (10.1.6.5)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 
(1208)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1208 (1208)<br>
&nbsp;&nbsp;&nbsp; Length: 1047<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x39bc (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 200 OK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 200<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP 
10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact:
&lt;sip:202.125.84.171:1571&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type:
application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 679<br>
&nbsp;&nbsp;&nbsp; Message body<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Session Description
Protocol<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Description Protocol Version (v): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Username: -<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session ID: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Version: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Name (s): session<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Information (c): IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Information (b): CT:1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Modifier: CT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Value: 1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time
Description, active time (t): 0 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Start Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Stop Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): audio 1572 RTP/AVP 97 111 112 6 0 8 4
5 3 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1572<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 97<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 111<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 112<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 16000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMU<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.723<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 8000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: GSM 06.10<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): video 1574 RTP/AVP 34 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: video<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1574<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.263<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.261<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp;&nbsp; 73 15.042612&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
10.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP/SDP&nbsp; Status: 200 OK, with session description<br><br>
Frame 73 (1081 bytes on wire, 1081 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:07.229570000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.489590000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 15.042612000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 73<br>
&nbsp;&nbsp;&nbsp; Packet Length: 1081 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 1081 bytes<br>
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d<br>
&nbsp;&nbsp;&nbsp; Destination: 00:50:fc:b1:ea:9d (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Source: 00:00:24:c2:01:f4 (10.1.6.1)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
10.1.6.5 (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 1067<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd921 (55585)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 127<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x2f72 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 10.1.6.5 (10.1.6.5)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 
(1208)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1208 (1208)<br>
&nbsp;&nbsp;&nbsp; Length: 1047<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x39bc (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 200 OK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 200<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: True<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Suspected resend of frame:
71<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP 
10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact:
&lt;sip:202.125.84.171:1571&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type:
application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 679<br>
&nbsp;&nbsp;&nbsp; Message body<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Session Description
Protocol<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Description Protocol Version (v): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Username: -<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session ID: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Version: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Name (s): session<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Information (c): IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Information (b): CT:1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Modifier: CT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Value: 1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time
Description, active time (t): 0 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Start Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Stop Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): audio 1572 RTP/AVP 97 111 112 6 0 8 4
5 3 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1572<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 97<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 111<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 112<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 16000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMU<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.723<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 8000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: GSM 06.10<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): video 1574 RTP/AVP 34 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: video<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1574<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.263<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.261<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 121 16.043599&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
10.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP/SDP&nbsp; Status: 200 OK, with session description<br><br>
Frame 121 (1081 bytes on wire, 1081 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:08.230557000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 1.000987000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 16.043599000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 121<br>
&nbsp;&nbsp;&nbsp; Packet Length: 1081 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 1081 bytes<br>
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d<br>
&nbsp;&nbsp;&nbsp; Destination: 00:50:fc:b1:ea:9d (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Source: 00:00:24:c2:01:f4 (10.1.6.1)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
10.1.6.5 (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 1067<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd923 (55587)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 127<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x2f70 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 10.1.6.5 (10.1.6.5)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 
(1208)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1208 (1208)<br>
&nbsp;&nbsp;&nbsp; Length: 1047<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x39bc (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 200 OK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 200<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: True<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Suspected resend of frame:
71<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP 
10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact:
&lt;sip:202.125.84.171:1571&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type:
application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 679<br>
&nbsp;&nbsp;&nbsp; Message body<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Session Description
Protocol<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Description Protocol Version (v): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Username: -<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session ID: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Version: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Name (s): session<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Information (c): IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Information (b): CT:1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Modifier: CT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Value: 1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time
Description, active time (t): 0 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Start Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Stop Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): audio 1572 RTP/AVP 97 111 112 6 0 8 4
5 3 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1572<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 97<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 111<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 112<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 16000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMU<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.723<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 8000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: GSM 06.10<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): video 1574 RTP/AVP 34 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: video<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1574<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.263<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.261<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 166 16.881442&nbsp;&nbsp;
10.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Request: ACK
sip:202.125.84.171:1571<br><br>
Frame 166 (374 bytes on wire, 374 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:09.068400000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.837843000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 16.881442000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 166<br>
&nbsp;&nbsp;&nbsp; Packet Length: 374 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 374 bytes<br>
Ethernet II, Src: 00:50:fc:b1:ea:9d, Dst: 00:00:24:c2:01:f4<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f4 (10.1.6.1)<br>
&nbsp;&nbsp;&nbsp; Source: 00:50:fc:b1:ea:9d (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 10.1.6.5 (10.1.6.5), Dst Addr:
202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 360<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd431 (54321)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x3625 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 10.1.6.5 (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.171 (202.125.84.171)<br>
User Datagram Protocol, Src Port: 1208 (1208), Dst Port: 1571 
(1571)<br>
&nbsp;&nbsp;&nbsp; Source port: 1208 (1208)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Length: 340<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x37c0 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Request-Line: ACK sip:202.125.84.171:1571 
SIP/2.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Method: ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
10.1.6.5:1208<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Max-Forwards: 70<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 176 17.012456&nbsp;&nbsp;
10.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Request: ACK
sip:202.125.84.171:1571<br><br>
Frame 176 (374 bytes on wire, 374 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:09.199414000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.131014000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 17.012456000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 176<br>
&nbsp;&nbsp;&nbsp; Packet Length: 374 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 374 bytes<br>
Ethernet II, Src: 00:50:fc:b1:ea:9d, Dst: 00:00:24:c2:01:f4<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f4 (10.1.6.1)<br>
&nbsp;&nbsp;&nbsp; Source: 00:50:fc:b1:ea:9d (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 10.1.6.5 (10.1.6.5), Dst Addr:
202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 360<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd43a (54330)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x361c (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 10.1.6.5 (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.171 (202.125.84.171)<br>
User Datagram Protocol, Src Port: 1208 (1208), Dst Port: 1571 
(1571)<br>
&nbsp;&nbsp;&nbsp; Source port: 1208 (1208)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Length: 340<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x37c0 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Request-Line: ACK sip:202.125.84.171:1571 
SIP/2.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Method: ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
10.1.6.5:1208<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Max-Forwards: 70<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 178 17.041945&nbsp;&nbsp;
10.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Request: ACK
sip:202.125.84.171:1571<br><br>
Frame 178 (374 bytes on wire, 374 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:09.228903000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.029489000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 17.041945000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 178<br>
&nbsp;&nbsp;&nbsp; Packet Length: 374 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 374 bytes<br>
Ethernet II, Src: 00:50:fc:b1:ea:9d, Dst: 00:00:24:c2:01:f4<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f4 (10.1.6.1)<br>
&nbsp;&nbsp;&nbsp; Source: 00:50:fc:b1:ea:9d (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 10.1.6.5 (10.1.6.5), Dst Addr:
202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 360<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd43c (54332)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x361a (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 10.1.6.5 (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.171 (202.125.84.171)<br>
User Datagram Protocol, Src Port: 1208 (1208), Dst Port: 1571 
(1571)<br>
&nbsp;&nbsp;&nbsp; Source port: 1208 (1208)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Length: 340<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x37c0 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Request-Line: ACK sip:202.125.84.171:1571 
SIP/2.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Method: ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
10.1.6.5:1208<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Max-Forwards: 70<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp; 2978 78.302363&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
10.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Request: BYE
sip:10.1.6.5:60324<br><br>
Frame 2978 (375 bytes on wire, 375 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:36:10.489321000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 61.260418000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 78.302363000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 2978<br>
&nbsp;&nbsp;&nbsp; Packet Length: 375 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 375 bytes<br>
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d<br>
&nbsp;&nbsp;&nbsp; Destination: 00:50:fc:b1:ea:9d (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Source: 00:00:24:c2:01:f4 (10.1.6.1)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
10.1.6.5 (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 361<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd965 (55653)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 127<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x31f0 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 10.1.6.5 (10.1.6.5)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 
(1208)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1208 (1208)<br>
&nbsp;&nbsp;&nbsp; Length: 341<br>
&nbsp;&nbsp;&nbsp; Checksum: 0xbde1 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Request-Line: BYE sip:10.1.6.5:60324 SIP/2.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Method: BYE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.171:1571<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Max-Forwards: 70<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 BYE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp; 2993 78.789133&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
10.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Request: BYE
sip:10.1.6.5:60324<br><br>
Frame 2993 (375 bytes on wire, 375 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:36:10.976091000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.486770000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 78.789133000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 2993<br>
&nbsp;&nbsp;&nbsp; Packet Length: 375 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 375 bytes<br>
Ethernet II, Src: 00:00:24:c2:01:f4, Dst: 00:50:fc:b1:ea:9d<br>
&nbsp;&nbsp;&nbsp; Destination: 00:50:fc:b1:ea:9d (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Source: 00:00:24:c2:01:f4 (10.1.6.1)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
10.1.6.5 (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 361<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd96d (55661)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 127<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x31e8 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 10.1.6.5 (10.1.6.5)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 1208 
(1208)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1208 (1208)<br>
&nbsp;&nbsp;&nbsp; Length: 341<br>
&nbsp;&nbsp;&nbsp; Checksum: 0xbde1 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Request-Line: BYE sip:10.1.6.5:60324 SIP/2.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Method: BYE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: True<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Suspected resend of frame:
2978<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.171:1571<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Max-Forwards: 70<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 BYE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp; 2995 79.313436&nbsp;&nbsp;
10.1.6.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status: 200 OK<br><br>
Frame 2995 (341 bytes on wire, 341 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:36:11.500394000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.524303000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 79.313436000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 2995<br>
&nbsp;&nbsp;&nbsp; Packet Length: 341 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 341 bytes<br>
Ethernet II, Src: 00:50:fc:b1:ea:9d, Dst: 00:00:24:c2:01:f4<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f4 (10.1.6.1)<br>
&nbsp;&nbsp;&nbsp; Source: 00:50:fc:b1:ea:9d (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 10.1.6.5 (10.1.6.5), Dst Addr:
202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 327<br>
&nbsp;&nbsp;&nbsp; Identification: 0xdf2a (57130)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x2b4d (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 10.1.6.5 (10.1.6.5)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.171 (202.125.84.171)<br>
User Datagram Protocol, Src Port: 1208 (1208), Dst Port: 1571 
(1571)<br>
&nbsp;&nbsp;&nbsp; Source port: 1208 (1208)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Length: 307<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x5406 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 200 OK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 200<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.171:1571<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@10.1.6.5<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 BYE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
<br>
</font><b>Capture At the External Machine (Host 2)<br><br>
</b><font face="Courier New, Courier">No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 109 31.434557&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP/SDP&nbsp;
Request: INVITE sip:user@202.125.84.171:1571, with session
description<br><br>
Frame 109 (1112 bytes on wire, 1112 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:19.153166000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 31.434557000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 31.434557000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 109<br>
&nbsp;&nbsp;&nbsp; Packet Length: 1112 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 1112 bytes<br>
Ethernet II, Src: 00:00:24:c2:01:f5, Dst: 00:40:f4:3d:66:5f<br>
&nbsp;&nbsp;&nbsp; Destination: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Source: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.170 (202.125.84.170), Dst Addr:
202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 1098<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd3d4 (54228)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 127<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x257e (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.171 (202.125.84.171)<br>
User Datagram Protocol, Src Port: 60323 (60323), Dst Port: 1571
(1571)<br>
&nbsp;&nbsp;&nbsp; Source port: 60323 (60323)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Length: 1078<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x899c (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Request-Line: INVITE sip:user@202.125.84.171:1571
SIP/2.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Method: INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Max-Forwards: 70<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact:
&lt;sip:202.125.84.170:60324&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type:
application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 681<br>
&nbsp;&nbsp;&nbsp; Message body<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Session Description
Protocol<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Description Protocol Version (v): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Username: -<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session ID: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Version: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address: 202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Name (s): session<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Information (c): IN IP4 202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address: 202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Information (b): CT:1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Modifier: CT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Value: 1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time
Description, active time (t): 0 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Start Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Stop Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): audio 60326 RTP/AVP 97 111 112 6 0 8 4
5 3 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 60326<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 97<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 111<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 112<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 16000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMU<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.723<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 8000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: GSM 06.10<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:aINkrSXVFlOw/LgTKp5bHe1D1a/vQi7wV59gwbXEtRY<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: aINkrSXVFlOw/LgTKp5bHe1D1a/vQi7wV59gwbXEtRY<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): video 60328 RTP/AVP 34 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: video<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 60328<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.263<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.261<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:9X9PloS9X/sgFGWluGGzdFVMn9iEMyaOMVKenrIlfYw<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: 9X9PloS9X/sgFGWluGGzdFVMn9iEMyaOMVKenrIlfYw<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 110 31.440348&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status: 100 Trying<br><br>
Frame 110 (355 bytes on wire, 355 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:19.158957000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.005791000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 31.440348000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 110<br>
&nbsp;&nbsp;&nbsp; Packet Length: 355 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 355 bytes<br>
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Source: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 341<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd91e (55582)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x2229 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.170 (202.125.84.170)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324
(60324)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 60324 (60324)<br>
&nbsp;&nbsp;&nbsp; Length: 321<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x2dd3 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 100 Trying<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 100<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 111 31.440840&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status: 180 Ringing<br><br>
Frame 111 (356 bytes on wire, 356 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:19.159449000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.000492000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 31.440840000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 111<br>
&nbsp;&nbsp;&nbsp; Packet Length: 356 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 356 bytes<br>
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Source: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 342<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd91f (55583)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x2227 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.170 (202.125.84.170)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324
(60324)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 60324 (60324)<br>
&nbsp;&nbsp;&nbsp; Length: 322<br>
&nbsp;&nbsp;&nbsp; Checksum: 0xaef6 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 180 Ringing<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 180<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 113 31.782481&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP/SDP&nbsp;
Status: 200 OK, with session description<br><br>
Frame 113 (1099 bytes on wire, 1099 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:19.501090000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.341641000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 31.782481000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 113<br>
&nbsp;&nbsp;&nbsp; Packet Length: 1099 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 1099 bytes<br>
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Source: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 1085<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd920 (55584)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x1f3f (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.170 (202.125.84.170)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324
(60324)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 60324 (60324)<br>
&nbsp;&nbsp;&nbsp; Length: 1065<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x9693 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 200 OK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 200<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact:
&lt;sip:202.125.84.171:1571&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type:
application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 679<br>
&nbsp;&nbsp;&nbsp; Message body<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Session Description
Protocol<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Description Protocol Version (v): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Username: -<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session ID: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Version: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Name (s): session<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Information (c): IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Information (b): CT:1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Modifier: CT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Value: 1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time
Description, active time (t): 0 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Start Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Stop Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): audio 1572 RTP/AVP 97 111 112 6 0 8 4
5 3 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1572<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 97<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 111<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 112<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 16000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMU<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.723<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 8000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: GSM 06.10<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): video 1574 RTP/AVP 34 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: video<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1574<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.263<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.261<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 115 32.271844&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP/SDP&nbsp;
Status: 200 OK, with session description<br><br>
Frame 115 (1099 bytes on wire, 1099 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:19.990453000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.489363000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 32.271844000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 115<br>
&nbsp;&nbsp;&nbsp; Packet Length: 1099 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 1099 bytes<br>
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Source: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 1085<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd921 (55585)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x1f3e (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.170 (202.125.84.170)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324
(60324)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 60324 (60324)<br>
&nbsp;&nbsp;&nbsp; Length: 1065<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x9693 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 200 OK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 200<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: True<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Suspected resend of frame:
113<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact:
&lt;sip:202.125.84.171:1571&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type:
application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 679<br>
&nbsp;&nbsp;&nbsp; Message body<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Session Description
Protocol<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Description Protocol Version (v): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Username: -<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session ID: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Version: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Name (s): session<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Information (c): IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Information (b): CT:1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Modifier: CT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Value: 1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time
Description, active time (t): 0 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Start Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Stop Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): audio 1572 RTP/AVP 97 111 112 6 0 8 4
5 3 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1572<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 97<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 111<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 112<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 16000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMU<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.723<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 8000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: GSM 06.10<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): video 1574 RTP/AVP 34 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: video<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1574<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.263<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.261<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 164 33.272848&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP/SDP&nbsp;
Status: 200 OK, with session description<br><br>
Frame 164 (1099 bytes on wire, 1099 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:20.991457000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 1.001004000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 33.272848000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 164<br>
&nbsp;&nbsp;&nbsp; Packet Length: 1099 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 1099 bytes<br>
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Source: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 1085<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd923 (55587)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x1f3c (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.170 (202.125.84.170)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324
(60324)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 60324 (60324)<br>
&nbsp;&nbsp;&nbsp; Length: 1065<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x9693 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 200 OK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 200<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: True<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Suspected resend of frame:
113<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact:
&lt;sip:202.125.84.171:1571&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type:
application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 679<br>
&nbsp;&nbsp;&nbsp; Message body<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Session Description
Protocol<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Description Protocol Version (v): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Username: -<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session ID: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Version: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Name (s): session<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Information (c): IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Information (b): CT:1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Modifier: CT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Value: 1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time
Description, active time (t): 0 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Start Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Stop Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): audio 1572 RTP/AVP 97 111 112 6 0 8 4
5 3 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1572<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 97<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 111<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 112<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 16000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMU<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.723<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 8000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: GSM 06.10<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): video 1574 RTP/AVP 34 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: video<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1574<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.263<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.261<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 211 34.117383&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Request: ACK
sip:202.125.84.171:1571<br><br>
Frame 211 (387 bytes on wire, 387 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:21.835992000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.844535000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 34.117383000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 211<br>
&nbsp;&nbsp;&nbsp; Packet Length: 387 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 387 bytes<br>
Ethernet II, Src: 00:00:24:c2:01:f5, Dst: 00:40:f4:3d:66:5f<br>
&nbsp;&nbsp;&nbsp; Destination: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Source: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.170 (202.125.84.170), Dst Addr:
202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 373<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd431 (54321)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 127<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x27f6 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.171 (202.125.84.171)<br>
User Datagram Protocol, Src Port: 60323 (60323), Dst Port: 1571
(1571)<br>
&nbsp;&nbsp;&nbsp; Source port: 60323 (60323)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Length: 353<br>
&nbsp;&nbsp;&nbsp; Checksum: 0xa19b (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Request-Line: ACK sip:202.125.84.171:1571 
SIP/2.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Method: ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Max-Forwards: 70<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 221 34.247583&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Request: ACK
sip:202.125.84.171:1571<br><br>
Frame 221 (387 bytes on wire, 387 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:21.966192000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.130200000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 34.247583000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 221<br>
&nbsp;&nbsp;&nbsp; Packet Length: 387 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 387 bytes<br>
Ethernet II, Src: 00:00:24:c2:01:f5, Dst: 00:40:f4:3d:66:5f<br>
&nbsp;&nbsp;&nbsp; Destination: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Source: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.170 (202.125.84.170), Dst Addr:
202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 373<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd43a (54330)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 127<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x27ed (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.171 (202.125.84.171)<br>
User Datagram Protocol, Src Port: 60323 (60323), Dst Port: 1571
(1571)<br>
&nbsp;&nbsp;&nbsp; Source port: 60323 (60323)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Length: 353<br>
&nbsp;&nbsp;&nbsp; Checksum: 0xa19b (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Request-Line: ACK sip:202.125.84.171:1571 
SIP/2.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Method: ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Max-Forwards: 70<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 223 34.277092&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SIP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Request: ACK
sip:202.125.84.171:1571<br><br>
Frame 223 (387 bytes on wire, 387 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:21.995701000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.029509000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 34.277092000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 223<br>
&nbsp;&nbsp;&nbsp; Packet Length: 387 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 387 bytes<br>
Ethernet II, Src: 00:00:24:c2:01:f5, Dst: 00:40:f4:3d:66:5f<br>
&nbsp;&nbsp;&nbsp; Destination: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Source: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.170 (202.125.84.170), Dst Addr:
202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 373<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd43c (54332)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 127<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x27eb (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.171 (202.125.84.171)<br>
User Datagram Protocol, Src Port: 60323 (60323), Dst Port: 1571
(1571)<br>
&nbsp;&nbsp;&nbsp; Source port: 60323 (60323)<br>
&nbsp;&nbsp;&nbsp; Destination port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Length: 353<br>
&nbsp;&nbsp;&nbsp; Checksum: 0xa19b (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Request-Line: ACK sip:202.125.84.171:1571 
SIP/2.0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Method: ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: False<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Max-Forwards: 70<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 ACK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 0<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 262 35.272771&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP/SDP&nbsp;
Status: 200 OK, with session description<br><br>
Frame 262 (1099 bytes on wire, 1099 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:22.991380000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 0.995679000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 35.272771000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 262<br>
&nbsp;&nbsp;&nbsp; Packet Length: 1099 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 1099 bytes<br>
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Source: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 1085<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd926 (55590)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x1f39 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.170 (202.125.84.170)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324
(60324)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 60324 (60324)<br>
&nbsp;&nbsp;&nbsp; Length: 1065<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x9693 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 200 OK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 200<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: True<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Suspected resend of frame:
113<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact:
&lt;sip:202.125.84.171:1571&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type:
application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 679<br>
&nbsp;&nbsp;&nbsp; Message body<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Session Description
Protocol<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Description Protocol Version (v): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Username: -<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session ID: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Version: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Name (s): session<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Information (c): IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Information (b): CT:1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Modifier: CT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Value: 1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time
Description, active time (t): 0 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Start Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Stop Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): audio 1572 RTP/AVP 97 111 112 6 0 8 4
5 3 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1572<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 97<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 111<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 112<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 16000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMU<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.723<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 8000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: GSM 06.10<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): video 1574 RTP/AVP 34 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: video<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1574<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.263<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.261<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 416 39.270667&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP/SDP&nbsp;
Status: 200 OK, with session description<br><br>
Frame 416 (1099 bytes on wire, 1099 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:26.989276000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 3.997896000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 39.270667000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 416<br>
&nbsp;&nbsp;&nbsp; Packet Length: 1099 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 1099 bytes<br>
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Source: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 1085<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd92a (55594)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x1f35 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.170 (202.125.84.170)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324
(60324)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 60324 (60324)<br>
&nbsp;&nbsp;&nbsp; Length: 1065<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x9693 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 200 OK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 200<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: True<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Suspected resend of frame:
113<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact:
&lt;sip:202.125.84.171:1571&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type:
application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 679<br>
&nbsp;&nbsp;&nbsp; Message body<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Session Description
Protocol<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Description Protocol Version (v): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Username: -<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session ID: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Version: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Name (s): session<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Information (c): IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Information (b): CT:1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Modifier: CT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Value: 1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time
Description, active time (t): 0 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Start Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Stop Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): audio 1572 RTP/AVP 97 111 112 6 0 8 4
5 3 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1572<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 97<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 111<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 112<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 16000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMU<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.723<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 8000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: GSM 06.10<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): video 1574 RTP/AVP 34 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: video<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1574<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.263<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.261<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp;&nbsp; 586 47.270357&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP/SDP&nbsp;
Status: 200 OK, with session description<br><br>
Frame 586 (1099 bytes on wire, 1099 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:34.988966000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 7.999690000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 47.270357000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 586<br>
&nbsp;&nbsp;&nbsp; Packet Length: 1099 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 1099 bytes<br>
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Source: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 1085<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd92e (55598)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x1f31 (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.170 (202.125.84.170)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324
(60324)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 60324 (60324)<br>
&nbsp;&nbsp;&nbsp; Length: 1065<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x9693 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 200 OK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 200<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: True<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Suspected resend of frame:
113<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact:
&lt;sip:202.125.84.171:1571&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type:
application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 679<br>
&nbsp;&nbsp;&nbsp; Message body<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Session Description
Protocol<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Description Protocol Version (v): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Username: -<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session ID: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Version: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Name (s): session<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Information (c): IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Information (b): CT:1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Modifier: CT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Value: 1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time
Description, active time (t): 0 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Start Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Stop Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): audio 1572 RTP/AVP 97 111 112 6 0 8 4
5 3 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1572<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 97<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 111<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 112<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 16000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMU<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.723<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 8000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: GSM 06.10<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): video 1574 RTP/AVP 34 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: video<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1574<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.263<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.261<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br><br>
No.&nbsp;&nbsp;&nbsp;&nbsp;
Time&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Info<br>
&nbsp;&nbsp; 1275 63.270736&nbsp;&nbsp;
202.125.84.171&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
202.125.84.170&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP/SDP&nbsp;
Status: 200 OK, with session description<br><br>
Frame 1275 (1099 bytes on wire, 1099 bytes captured)<br>
&nbsp;&nbsp;&nbsp; Arrival Time: Dec 14, 2004 11:35:50.989345000<br>
&nbsp;&nbsp;&nbsp; Time delta from previous packet: 16.000379000
seconds<br>
&nbsp;&nbsp;&nbsp; Time since reference or first frame: 63.270736000
seconds<br>
&nbsp;&nbsp;&nbsp; Frame Number: 1275<br>
&nbsp;&nbsp;&nbsp; Packet Length: 1099 bytes<br>
&nbsp;&nbsp;&nbsp; Capture Length: 1099 bytes<br>
Ethernet II, Src: 00:40:f4:3d:66:5f, Dst: 00:00:24:c2:01:f5<br>
&nbsp;&nbsp;&nbsp; Destination: 00:00:24:c2:01:f5 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Source: 00:40:f4:3d:66:5f (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Type: IP (0x0800)<br>
Internet Protocol, Src Addr: 202.125.84.171 (202.125.84.171), Dst Addr:
202.125.84.170 (202.125.84.170)<br>
&nbsp;&nbsp;&nbsp; Version: 4<br>
&nbsp;&nbsp;&nbsp; Header length: 20 bytes<br>
&nbsp;&nbsp;&nbsp; Differentiated Services Field: 0x00 (DSCP 0x00:
Default; ECN: 0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0000 00.. = Differentiated
Services Codepoint: Default (0x00)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ..0. = ECN-Capable
Transport (ECT): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .... ...0 = ECN-CE: 0<br>
&nbsp;&nbsp;&nbsp; Total Length: 1085<br>
&nbsp;&nbsp;&nbsp; Identification: 0xd945 (55621)<br>
&nbsp;&nbsp;&nbsp; Flags: 0x00<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0... = Reserved bit: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .0.. = Don't fragment: Not
set<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ..0. = More fragments: Not
set<br>
&nbsp;&nbsp;&nbsp; Fragment offset: 0<br>
&nbsp;&nbsp;&nbsp; Time to live: 128<br>
&nbsp;&nbsp;&nbsp; Protocol: UDP (0x11)<br>
&nbsp;&nbsp;&nbsp; Header checksum: 0x1f1a (correct)<br>
&nbsp;&nbsp;&nbsp; Source: 202.125.84.171 (202.125.84.171)<br>
&nbsp;&nbsp;&nbsp; Destination: 202.125.84.170 (202.125.84.170)<br>
User Datagram Protocol, Src Port: 1571 (1571), Dst Port: 60324
(60324)<br>
&nbsp;&nbsp;&nbsp; Source port: 1571 (1571)<br>
&nbsp;&nbsp;&nbsp; Destination port: 60324 (60324)<br>
&nbsp;&nbsp;&nbsp; Length: 1065<br>
&nbsp;&nbsp;&nbsp; Checksum: 0x9693 (correct)<br>
Session Initiation Protocol<br>
&nbsp;&nbsp;&nbsp; Status-Line: SIP/2.0 200 OK<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Status-Code: 200<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Resent Packet: True<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Suspected resend of frame:
113<br>
&nbsp;&nbsp;&nbsp; Message Header<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Via: SIP/2.0/UDP
202.125.84.170:60324<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: &quot;intoalg2&quot;
&lt;sip:intoalg2&gt;;tag=3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
Display info: &quot;intoalg2&quot; <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
from address: sip:intoalg2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: 3a35760de42649f28e341a80a9edf4f7<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:
&lt;sip:user@202.125.84.171&gt;;tag=f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP to
address: sip:user@202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SIP
tag: f025608bd41248b48746df9fd86f6fc9<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call-ID:
04c5ac506c4344fe9c7ceb4e7cefc0b2@202.125.84.170<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CSeq: 1 INVITE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Contact:
&lt;sip:202.125.84.171:1571&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; User-Agent: RTC/1.2<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Type:
application/sdp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Content-Length: 679<br>
&nbsp;&nbsp;&nbsp; Message body<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Session Description
Protocol<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Description Protocol Version (v): 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner/Creator, Session Id (o): - 0 0 IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Username: -<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session ID: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Version: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Owner Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Name (s): session<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Information (c): IN IP4 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Network Type: IN<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address Type: IP4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection Address: 202.125.84.171<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Information (b): CT:1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Modifier: CT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Bandwidth Value: 1000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time
Description, active time (t): 0 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Start Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Session Stop Time: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): audio 1572 RTP/AVP 97 111 112 6 0 8 4
5 3 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1572<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 97<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 111<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 112<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 16000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMU<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.711 PCMA<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T G.723<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: DVI4 8000 samples/s<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: GSM 06.10<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: 9ELIKPMLAfwRQJG49w4Dmo+nh9CBk1Ulq1sGJeQnsVE<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 97 red/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 SIREN/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 111 bitrate=16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 G7221/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 112 bitrate=24000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 6 DVI4/16000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 4 G723/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 5 DVI4/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 3 GSM/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): fmtp:101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: fmtp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 101 0-16<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Description, name and address (m): video 1574 RTP/AVP 34 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Type: video<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Port: 1574<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.263<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Format: ITU-T H.261<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Encryption Key (k):
base64:IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Type: base64<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Key Data: IuScUg0Dn3LfdHEvyrzZ9wE0wB36+3KMZ1c3HjrWeXg<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 34 H263/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): rtpmap:31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: rtpmap<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: 31 H261/90000<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media
Attribute (a): encryption:optional<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Fieldname: encryption<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Attribute Value: optional<br><br>
</font></body>
</html>

--=====================_6427312==.ALT--



--===============1965576048==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1965576048==--




From sip-bounces@ietf.org  Sat Dec 18 04:23:49 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03501
	for <sip-web-archive@ietf.org>; Sat, 18 Dec 2004 04:23:49 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CfaxN-0004zv-Px
	for sip-web-archive@ietf.org; Sat, 18 Dec 2004 04:32:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cfakz-00064c-Qm; Sat, 18 Dec 2004 04:20:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CfagX-000528-GO
	for sip@megatron.ietf.org; Sat, 18 Dec 2004 04:15:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03056
	for <sip@ietf.org>; Sat, 18 Dec 2004 04:15:29 -0500 (EST)
Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cfaor-0004lN-Gs
	for sip@ietf.org; Sat, 18 Dec 2004 04:24:38 -0500
Received: from Nataraju (ikw@[192.168.2.115])
	by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id
	iBI9ALo09356; Sat, 18 Dec 2004 14:40:24 +0530
From: "Nataraju A B" <bnataraju@kodiaknetworks.com>
To: "'Wang, Jin-Gen'" <Jin-Gen.Wang@Level3.com>, <sip@ietf.org>
Subject: RE: [Sip] a question about the tag in From or To header
Date: Sat, 18 Dec 2004 14:35:25 +0530
Message-ID: <001b01c4e4e0$b901d9d0$7302a8c0@Nataraju>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <11FD90E74279C0489ECB6793F227C847044BFBDE@idc1exc0002.corp.global.level3.com>
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: 7bit
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: 7bit


Best Regards,
Nataraju A.B.
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Wang, Jin-Gen
Sent: Saturday, December 18, 2004 1:04 AM
To: sip@ietf.org
Subject: [Sip] a question about the tag in From or To header

We have a debate on how to interpret the following paragraph (RFC 3261,
section 19.3):

===========
19.3 Tags
   ...

   When a tag is generated by a UA for insertion into a request or
   response, it MUST be globally unique and cryptographically random
   with at least 32 bits of randomness.  A property of this selection
   requirement is that a UA will place a different tag into the From
   header of an INVITE than it would place into the To header of the
   response to the same INVITE.  This is needed in order for a UA to
   invite itself to a session, a common case for "hairpinning" of calls
   in PSTN gateways.  Similarly, two INVITEs for different calls will
   have different From tags, and two responses for different calls will
   have different To tags.

   ...
===========

Interpretation 1: A tag needs to be globally unique across space (aka
UAs) but not across time because Call-ID (section 8.1.1.4) is already
unique across space and time for calls. So a same UAC can use a same
>From tag in different calls it imitates. And a same UAS can use a same
To tag to respond to different calls. A same UA uses different tags in
>From and To headers. Different UAs use different tags.

[ABN] probably using same from tag for all the outgoing calls from this
entity is OK this eases to some extent for identifying the calling user.
But using same from tag  for each of the outgoing calls as well as same
to tag for answering all the incoming calls may lead serious security
issues...

Interpretation 2: A tag needs to be different for each call. So a same
UAC has to use two different tags in From header when it initiates two
different calls. And a same UAS has to use different tags in To headers
for different calls. 

[ABN] this is a better option....
In this case we may need to have the mapping between the tag and the
user who generated that particular tag. This might add some complexity
in identifying the end user for that call...

If security is not much of an issue then having the same tag for all the
generated (from tag) / answered (to tag) calls would be fine... in this
case the tag to user mapping would be simplified...

Finally it boil down to complexity vs security issue...

We would like to hear from the list which way we should interpret the
above paragraph or what is the right interpretation if both
interpretations are not accurate.

Thanks.


Jin-Gen Wang
Level3 Communications, Inc.



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec 20 00:41:55 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15177
	for <sip-web-archive@ietf.org>; Mon, 20 Dec 2004 00:41:55 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgGS9-0006XS-Ll
	for sip-web-archive@ietf.org; Mon, 20 Dec 2004 00:51:29 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgGGO-0004wo-4y; Mon, 20 Dec 2004 00:39:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CgGFe-0004mz-1p
	for sip@megatron.ietf.org; Mon, 20 Dec 2004 00:38:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14955
	for <sip@ietf.org>; Mon, 20 Dec 2004 00:38:27 -0500 (EST)
From: wangy@bnuep.com
Received: from [219.131.222.47] (helo=172.16.5.119)
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CgGOV-0006Pn-GB
	for sip@ietf.org; Mon, 20 Dec 2004 00:48:01 -0500
Received: from [172.16.5.130] by 172.16.5.119 with StormMail ESMTP id
	23852.1112621526; Mon, 20 Dec 2004 13:41:21 +0800 (CST)
Received: from bnuep.com (localhost [127.0.0.1])
	by mailserver.bnuep.com (iPlanet Messaging Server 5.2 HotFix 1.21
	(built Sep
	8 2003)) with ESMTP id <0I90002JS9XBYS@mailserver.bnuep.com> for
	sip@ietf.org; Mon, 20 Dec 2004 13:29:35 +0800 (CST)
Received: from [47.153.135.63] by mailserver.bnuep.com (mshttpd); Mon,
	20 Dec 2004 13:29:35 +0800
Date: Mon, 20 Dec 2004 13:29:35 +0800
To: sip@ietf.org
Message-id: <135d813a7c.13a7c135d8@bnuep.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.21 (built Sep  8 2003)
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: zh-CN
Priority: normal
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Content-Transfer-Encoding: 7BIT
Subject: [Sip] About 403 Forbidden
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7BIT

Hi all,

When I reading the RFC 3261, about 403 Forbidden description as following
-----------------------------------------------------------------------
7.4.4 403 Forbidden

   The server understood the request, but is refusing to fulfill it.
   Authorization will not help, and the request SHOULD NOT be repeated.
----------------------------------------------------------------------
>From above description, what is the request? From my view,I think that "the request" is Client. right or not? BTW, if yes, how to understand the sentence of "the request SHOULD NOT be repeated"


Thanks,  
Paul


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec 20 02:48:05 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08098
	for <sip-web-archive@ietf.org>; Mon, 20 Dec 2004 02:48:05 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgIQE-0000wW-74
	for sip-web-archive@ietf.org; Mon, 20 Dec 2004 02:57:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgIEy-00088Q-OS; Mon, 20 Dec 2004 02:46:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CgICD-0007lH-Pr
	for sip@megatron.ietf.org; Mon, 20 Dec 2004 02:43:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07811
	for <sip@ietf.org>; Mon, 20 Dec 2004 02:43:08 -0500 (EST)
Received: from eastmail1.ntt-east.co.jp ([202.229.5.44]
	helo=evx1.enoc.east.ntt.co.jp)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgILQ-0000ou-N8
	for sip@ietf.org; Mon, 20 Dec 2004 02:52:41 -0500
Received: from emix1.enoc.east.ntt.co.jp 
	by evx1.enoc.east.ntt.co.jp with ESMTP id iBK7gVs27214;
	Mon, 20 Dec 2004 16:42:31 +0900 (JST)
Received: from cip11.noc.east.ntt.co.jp 
	by emix1.enoc.east.ntt.co.jp with ESMTP id iBK7gVj25908;
	Mon, 20 Dec 2004 16:42:31 +0900 (JST)
Received: from [10.8.52.30] ([10.8.52.30])
	by cip11.noc.east.ntt.co.jp (MOS 3.4.6-GR) with ESMTP id ATG09150;
	Mon, 20 Dec 2004 16:42:31 +0900 (JST)
Date: Mon, 20 Dec 2004 16:42:34 +0900
From: "Jun KOSHIKO(Office)" <j.koshiko@rdc.east.ntt.co.jp>
To: sip@ietf.org
Message-Id: <20041220162410.3E84.J.KOSHIKO@rdc.east.ntt.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.11.02 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Subject: [Sip] Priority and Resource Priority
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit

Hello,

I would like to know the difference between 'priority' in RFC3261 and
'Resource-Priority' in draft-ietf-sip-resource-priority-05.txt.

I'm looking for a means to recognize the difference between normal calls
and emergency calls, so that proxies can give priority to the emergency
calls (911(us)/112(eu)/119(jp)).

I found two headers defined in SIP. One is 'priority' in RFC3261 and the
other is 'Resource Priority' in draft-ietf-sip-resource-priority-05.txt.
Since they are both used for indicating the priority of a call, I can't
make up my mind of which header is more suitable for the emergency call. 

Would you please give me some advice?

Best regards,
Jun Koshiko

---------------------------------------------------------
Jun KOSHIKO
Next Generation Strategy
Research and Development Center
NTT-east Corporation

Telephone  +81 3 5359 5104
Facsimile  +81 3 5359 4768
E-mail: j.koshiko@rdc.east.ntt.co.jp
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
---------------------------------------------------------


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec 20 09:18:08 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00518
	for <sip-web-archive@ietf.org>; Mon, 20 Dec 2004 09:18:08 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgOVk-0001NF-2J
	for sip-web-archive@ietf.org; Mon, 20 Dec 2004 09:27:45 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgOJD-0001Pw-ED; Mon, 20 Dec 2004 09:14:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgOHh-00018h-1J; Mon, 20 Dec 2004 09:13:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00308;
	Mon, 20 Dec 2004 09:13:11 -0500 (EST)
Received: from amer-mta02.csc.com ([20.137.2.248])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgOQw-0001Fw-Go; Mon, 20 Dec 2004 09:22:47 -0500
Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245])
	by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id
	iBKED4OQ009102; Mon, 20 Dec 2004 09:13:06 -0500 (EST)
Subject: Re: [Sip] Priority and Resource Priority
To: "Jun KOSHIKO(Office)" <j.koshiko@rdc.east.ntt.co.jp>
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <OF9EEC5F87.49EE02E5-ON85256F70.004C4992-85256F70.004E1F21@csc.com>
From: Janet P Gunn <jgunn6@csc.com>
Date: Mon, 20 Dec 2004 09:13:17 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September
	14, 2004) at 12/20/2004 09:13:33 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc: sip@ietf.org, sip-bounces@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7





The  difference between the "priority" and "resource priority" fields are
described in  draft-ietf-sip-resource-priority-05.txt
"This header field is related to, but differs in semantics from, the
   'Priority' header field (RFC 3261 [RFC3261], Section 20.26).  The
   'Priority' header field describes the importance that the SIP request
   should have to the receiving human or its agent.  For example, that
   header may be factored into decisions about call routing to mobile
   devices and assistants and call acceptance when the call destination
   is busy.  The 'Priority' header field does not affect the usage of
   GSTN gateway or proxy resources, for example.  In addition, any User
   Agent Client (UAC) can assert any 'Priority' value, while access to
   resource priority values are subject to authorization."

The "Priority Header" is not actecd on by any intervening SIP elements, but
is simply a notification to the destination.

The "Resource Priority Header" MAY BE acted on by the intervening SIP
elements.

As I understand it, the neither is intended to identify a "911 type"
emergency call, though other mechanisms have been identified.

There is a separate mailing list that specifically addresses  SIP and "911
type" emergency calls. called sipping-emergency.

You can find information about joining the list at
https://www1.ietf.org/mailman/listinfo/sipping-emergency.

You can find the archives at
http://www1.ietf.org/mail-archive/web/sipping-emergency/current/index.html

There is also a new working group, ecrit  (Emergency Context Resolution
with Internet Technologies), being started which will address these issues


----------------------------------------------------------------------------------------.

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------




                                                                                                                             
                      "Jun                                                                                                   
                      KOSHIKO(Office)"         To:      sip@ietf.org                                                         
                      <j.koshiko               cc:                                                                           
                      @rdc.east.ntt.co         Subject: [Sip] Priority and Resource Priority                                 
                      .jp>                                                                                                   
                      Sent by:                                                                                               
                      sip-bounces                                                                                            
                                                                                                                             
                                                                                                                             
                      12/20/2004 02:42                                                                                       
                      AM                                                                                                     
                                                                                                                             
                                                                                                                             




Hello,

I would like to know the difference between 'priority' in RFC3261 and
'Resource-Priority' in draft-ietf-sip-resource-priority-05.txt.

I'm looking for a means to recognize the difference between normal calls
and emergency calls, so that proxies can give priority to the emergency
calls (911(us)/112(eu)/119(jp)).

I found two headers defined in SIP. One is 'priority' in RFC3261 and the
other is 'Resource Priority' in draft-ietf-sip-resource-priority-05.txt.
Since they are both used for indicating the priority of a call, I can't
make up my mind of which header is more suitable for the emergency call.

Would you please give me some advice?

Best regards,
Jun Koshiko

---------------------------------------------------------
Jun KOSHIKO
Next Generation Strategy
Research and Development Center
NTT-east Corporation

Telephone  +81 3 5359 5104
Facsimile  +81 3 5359 4768
E-mail: j.koshiko@rdc.east.ntt.co.jp
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
---------------------------------------------------------


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec 21 02:43:32 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12347
	for <sip-web-archive@ietf.org>; Tue, 21 Dec 2004 02:43:32 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cgepa-0003xs-CO
	for sip-web-archive@ietf.org; Tue, 21 Dec 2004 02:53:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cgeax-0008Pj-Gg; Tue, 21 Dec 2004 02:38:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CgeWq-0007d2-3C
	for sip@megatron.ietf.org; Tue, 21 Dec 2004 02:33:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11709
	for <sip@ietf.org>; Tue, 21 Dec 2004 02:33:54 -0500 (EST)
Received: from mgw1.alpha.co.jp ([210.250.201.67])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgegF-0003ik-Qq
	for sip@ietf.org; Tue, 21 Dec 2004 02:43:40 -0500
Received: from mgw1.alpha.co.jp (localhost [127.0.0.1])
	by check_out.mgw1.alpha.co.jp (Postfix) with ESMTP id EF1EF4E617
	for <sip@ietf.org>; Tue, 21 Dec 2004 16:33:38 +0900 (JST)
Received: from sps-0004.alpha.co.jp (sps-0004.alpha.co.jp [10.128.240.2])
	by init.mgw1.alpha.co.jp (Postfix) with SMTP id BA13C105403
	for <sip@ietf.org>; Tue, 21 Dec 2004 16:33:38 +0900 (JST)
Date: Tue, 21 Dec 2004 16:33:38 +0900
From: Norihiko Tashi <tashin@alpha.co.jp>
To: sip@ietf.org
Subject: Re: [Sip] Questions about early dialog
In-Reply-To: <000801c4e41f$92abaca0$7302a8c0@Nataraju>
References: <20041217091944.FEB7.TASHIN@alpha.co.jp>
	<000801c4e41f$92abaca0$7302a8c0@Nataraju>
Message-Id: <20041221094125.7D1D.TASHIN@alpha.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.10.04 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Content-Transfer-Encoding: 7bit
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Content-Transfer-Encoding: 7bit

Best regards,
Norihiko Tashi

> > [ABN] there can be multiple dialogs in a session.... when you send the
> > subscribe within session then that creates one more dialog as part of
> > the same session....

A dialog is "associated with" a session, so is not part of a session and
is not associated with only a session.

RFC3261 refers to this matter.


15 Terminating a Session

  This section describes the procedures for terminating a session
  established by SIP.  The state of the session and the state of the
  dialog are very closely related.  When a session is initiated with an
  INVITE, each 1xx or 2xx response from a distinct UAS creates a
  dialog, and if that response completes the offer/answer exchange, it
  also creates a session.  As a result, each session is "associated"
  with a single dialog - the one which resulted in its creation.  If an
  initial INVITE generates a non-2xx final response, that terminates
  all sessions (if any) and all dialogs (if any) that were created
  through responses to the request.  



Presumably, my question 1 is solved..
When first INVITE transaction fails, all sessions and all of dialogs
(because when forked, multiple dialog are created) 
and probably all of subscriptions will terminate.

Furthermore, in special cases, a session can exist without a dialog.
An example is as below.


 13.3.1 Processing of the INVITE
 The INVITE may contain a session description, in which case the UAS
 is being presented with an offer for that session.  It is possible
 that the user is already a participant in that session, even though
 the INVITE is outside of a dialog.  This can happen when a user is
 invited to the same multicast conference by multiple other
 participants.  If desired, the UAS MAY use identifiers within the
 session description to detect this duplication.


Probably, the definitions of "dialog" and "session" 
between you and me are different terminologically.

A dialog by SUBSCRIBE/REFER in your eyes is equivalent to a subscription
in my eyes.

A session in your eyes is equivalent to a dialog and a session 
by INVITE and all of subscriptions in my eyes.

RFC3261 and RFC3265 define theses terminology as below.

Dialog: A dialog is a peer-to-peer SIP relationship between two
  UAs that persists for some time.  A dialog is established by
  SIP messages, such as a 2xx response to an INVITE request.  A
  dialog is identified by a call identifier, local tag, and a
  remote tag.  A dialog was formerly known as a call leg in RFC
  2543.

Session: From the SDP specification: "A multimedia session is a
  set of multimedia senders and receivers and the data streams
  flowing from senders to receivers.  A multimedia conference is
  an example of a multimedia session." (RFC 2327 [1]) (A session
  as defined for SDP can comprise one or more RTP sessions.)  As
  defined, a callee can be invited several times, by different
  calls, to the same session.  If SDP is used, a session is
  defined by the concatenation of the SDP user name, session id,
  network type, address type, and address elements in the origin
  field.

Subscription: A subscription is a set of application state associated
  with a dialog.  This application state includes a pointer to the
  associated dialog, the event package name, and possibly an
  identification token.  Event packages will define additional
  subscription state information.  By definition, subscriptions
  exist in both a subscriber and a notifier.


> > Basically there can be multiple dialogs as part of the same session..
> > some thing similar to multiple transactions in a dialog...

Sorry, I can't understand why multiple dialogs with same dialog id
(call-id, from-tag and to-tag) can be created.

Since a dialog is identified by dialog id, only one dialog that have 
same dialog id can exist.

And, I think that a dialog is like a SIP-level virtual connection
(peer relationsip) between UAs that is target-refresh-capable.

INVITE, SUBSCRIBE and REFER methods can establish a virtual 
connection by only sending or receiving them outside a dialog.

So, if you want to establish new virtual connection, 
you have to send a INVITE, SUBSCRIBE or REFER message with 
different from-tag and call-id (outside the dialog).

If there are multiple dialogs, target refresh affect one dialog.

But, If target refreshed, this change affect all of continuing
mid-dialog messages.

So, I represent that a dialog can be shared by sessions and
subscriptions.

I agree that there can be multiple transactions in a dialog.





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec 21 06:58:41 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28892
	for <sip-web-archive@ietf.org>; Tue, 21 Dec 2004 06:58:41 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgioY-0001Eh-O6
	for sip-web-archive@ietf.org; Tue, 21 Dec 2004 07:08:31 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cgidi-000211-H3; Tue, 21 Dec 2004 06:57:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CgiU5-0000up-PE
	for sip@megatron.ietf.org; Tue, 21 Dec 2004 06:47:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28530
	for <sip@ietf.org>; Tue, 21 Dec 2004 06:47:19 -0500 (EST)
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgidY-00012n-27
	for sip@ietf.org; Tue, 21 Dec 2004 06:57:08 -0500
Received: from horh1.emsr.lucent.com (h135-17-1-40.lucent.com [135.17.1.40])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iBLBkm3D006275
	for <sip@ietf.org>; Tue, 21 Dec 2004 05:46:49 -0600 (CST)
Received: from new-wopr.eng.ascend.com (new-wopr.eng.ascend.com
	[135.140.53.19]) by horh1.emsr.lucent.com (8.11.7+Sun/EMS-1.5
	Solaris/emsr) id iBLBkmw27347 for <sip@ietf.org>;
	Tue, 21 Dec 2004 05:46:48 -0600 (CST)
Received: from illy.eng.ascend.com (illy.eng.ascend.com [135.140.53.129])
	by new-wopr.eng.ascend.com (8.11.6+Sun/8.10.2) with ESMTP id
	iBLBkla09106
	for <sip@ietf.org>; Tue, 21 Dec 2004 03:46:47 -0800 (PST)
Received: from shoshone (shoshone.india.ascend.com [135.254.196.55])
	by illy.eng.ascend.com (8.11.6+Sun/8.11.6) with ESMTP id iBLBkjE17600
	for <sip@ietf.org>; Tue, 21 Dec 2004 03:46:46 -0800 (PST)
From: Poojan Tanna <ptanna@lucent.com>
To: sip ietf <sip@ietf.org>
Content-Type: text/plain
Message-Id: <1103629604.2977.45.camel@shoshone.india.ascend.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 21 Dec 2004 17:16:44 +0530
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Subject: [Sip] Session-TImer Refreshing Mechanism.
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit

Hi,

I am facing one issue regarding session timer refreshing mechanism.
   
    a) As per draft-ietf-sip-session-timer-15.txt, the refresher should send
       the session refresh re-Invite/Update at half of the session expiration
       time.

      The excerpt from draft-ietf-sip-session-timer-15.txt, pg 12 is as
      follows:
      "  If the UAC must perform the refreshes, it computes the session
       expiration for that session.  The session expiration is the time of
       reception of the last 2xx response to a session refresh request on
       that dialog plus the session interval for that session.  If UA wishes
       to continue with the session beyond the session expiration, it MUST
       generate a refresh before the session expiration.  It is RECOMMENDED
       that this refresh be sent once half the session interval has elapsed.
       Additional procedures for this refresh are described in Section 10."

    b) Also regarding refreshee, draft-ietf-sip-session-timer-15.txt, pg 21
       is as follows:
      " Similarly, if the side not performing refreshes does not receive a
        session refresh request before the session expiration, they SHOULD
        send a BYE to terminate the session, slightly before the session
        expiration.  The minimum of 32 seconds and one third the session
        interval is RECOMMENDED."

     - Lets analyze the above two conditions with the session-timer
       as 90 secs:

                t0: session is UP and session-timer starts

       t1: t0 + 45: Refresher sends the re-Invite to refresh the session.

       t2: t1 + 15: Lets also assume that due to some reason, refreshee does
                    not receive re-Invite request.
 
                    But according to condition b), the refreshee should send
                    a BYE to the refresher.

       In the above scenario, refreshee sends BYE to terminate the session
       before re-Invite transaction timeout.

       I assume that after time t1, we should wait for ( 45 + 32 ) = 77 secs
       before refreshee would receive a BYE request. At the same time,
       refreshee is unaware since it haven't received a re-Invite request.

       Pl. let me know your views.

Thanks,
Poojan.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec 21 13:33:16 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06495
	for <sip-web-archive@ietf.org>; Tue, 21 Dec 2004 13:33:16 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgoyS-0003LO-6L
	for sip-web-archive@ietf.org; Tue, 21 Dec 2004 13:43:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cgojk-0004at-SH; Tue, 21 Dec 2004 13:27:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CgoXr-0002kF-Ez
	for sip@megatron.ietf.org; Tue, 21 Dec 2004 13:15:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05686
	for <sip@ietf.org>; Tue, 21 Dec 2004 13:15:36 -0500 (EST)
Received: from mx01.net.com ([134.56.3.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgohB-0002xg-Sm
	for sip@ietf.org; Tue, 21 Dec 2004 13:25:29 -0500
Received: from mx02-int.net.com (mx02-int.net.com [134.56.112.14])
	by mx01.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id
	iBLIJ47O023855; Tue, 21 Dec 2004 10:19:04 -0800 (PST)
Received: from fmt-ex01.net.com ([134.56.112.251])
	by mx02-int.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id
	iBLIIbG7023662; Tue, 21 Dec 2004 10:18:54 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Session-TImer Refreshing Mechanism.
Date: Tue, 21 Dec 2004 10:12:27 -0800
Message-ID: <985D4DC322E5ED46A3E183D8227094FB03E917E7@fmt-ex01.net.com>
Thread-Topic: [Sip] Session-TImer Refreshing Mechanism.
Thread-Index: AcTnVKzCJugMXccrQNqlb4T57niPOAAM/8HA
From: "Sreedhar Pampati" <Sreedhar_Pampati@net.com>
To: "Poojan Tanna" <ptanna@lucent.com>, "sip ietf" <sip@ietf.org>
X-Spam-Status: No, hits=-0.8 required=8.0 tests=AWL autolearn=ham version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on fmt-spam02
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Content-Transfer-Encoding: quoted-printable
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Content-Transfer-Encoding: quoted-printable

Poojan,
  I agree with you that it is a small anomaly with the Recommendations
in this draft, if you choose 90 seconds as the refresh duration. With
your calculations the UAC is not getting a chance to send one last
re-Invite (in its exponential back off retransmissions if using UDP).
However this is not an error situation. It can be a genuine BYE sent
from the UAS, since the callee hung-up the call. I don't know if it
needs any special treatment.

  However the draft also says the following in section 4:

4.  Session-Expires Header Field Definition
   However, 1800 seconds (30 minutes) is RECOMMENDED as the value for
the   Session-Expires header field.  In other words, SIP entities MUST
be prepared to handle Session-Expires header field values of any
duration greater than 90 seconds, but entities that insert the
Session-Expires header field  SHOULD NOT choose values less than 30
minutes.

For all theoretical purposes, the draft recommends 1800 seconds, which
should take care of this issue.

Cheers,
Sreedhar

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Poojan Tanna
Sent: Tuesday, December 21, 2004 3:47 AM
To: sip ietf
Subject: [Sip] Session-TImer Refreshing Mechanism.

Hi,

I am facing one issue regarding session timer refreshing mechanism.
  =20
    a) As per draft-ietf-sip-session-timer-15.txt, the refresher should
send
       the session refresh re-Invite/Update at half of the session
expiration
       time.

      The excerpt from draft-ietf-sip-session-timer-15.txt, pg 12 is as
      follows:
      "  If the UAC must perform the refreshes, it computes the session
       expiration for that session.  The session expiration is the time
of
       reception of the last 2xx response to a session refresh request
on
       that dialog plus the session interval for that session.  If UA
wishes
       to continue with the session beyond the session expiration, it
MUST
       generate a refresh before the session expiration.  It is
RECOMMENDED
       that this refresh be sent once half the session interval has
elapsed.
       Additional procedures for this refresh are described in Section
10."

    b) Also regarding refreshee, draft-ietf-sip-session-timer-15.txt, pg
21
       is as follows:
      " Similarly, if the side not performing refreshes does not receive
a
        session refresh request before the session expiration, they
SHOULD
        send a BYE to terminate the session, slightly before the session
        expiration.  The minimum of 32 seconds and one third the session
        interval is RECOMMENDED."

     - Lets analyze the above two conditions with the session-timer
       as 90 secs:

                t0: session is UP and session-timer starts

       t1: t0 + 45: Refresher sends the re-Invite to refresh the
session.

       t2: t1 + 15: Lets also assume that due to some reason, refreshee
does
                    not receive re-Invite request.
=20
                    But according to condition b), the refreshee should
send
                    a BYE to the refresher.

       In the above scenario, refreshee sends BYE to terminate the
session
       before re-Invite transaction timeout.

       I assume that after time t1, we should wait for ( 45 + 32 ) =3D =
77
secs
       before refreshee would receive a BYE request. At the same time,
       refreshee is unaware since it haven't received a re-Invite
request.

       Pl. let me know your views.

Thanks,
Poojan.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec 21 19:09:46 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23467
	for <sip-web-archive@ietf.org>; Tue, 21 Dec 2004 19:09:45 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CguBo-0006Ie-1n
	for sip-web-archive@ietf.org; Tue, 21 Dec 2004 19:17:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cgtjv-0003f6-9i; Tue, 21 Dec 2004 18:48:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgtZW-0007oe-B0; Tue, 21 Dec 2004 18:37:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20602;
	Tue, 21 Dec 2004 18:37:35 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgtYD-0002E0-Tr; Tue, 21 Dec 2004 18:36:23 -0500
Received: from ISI.EDU (adma.isi.edu [128.9.160.239])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iBLNNeQ24198;
	Tue, 21 Dec 2004 15:23:40 -0800 (PST)
Message-Id: <200412212323.iBLNNeQ24198@boreas.isi.edu>
To: ietf-announce@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 21 Dec 2004 15:23:40 -0800
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: rfc-ed@isi.edu
X-Spam-Score: -14.6 (--------------)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: sip@ietf.org, rfc-editor@rfc-editor.org
Subject: [Sip] BCP 98,
	RFC 3968 on The Internet Assigned Number Authority (IANA)
	Header Field Parameter Registry for the Session Initiation
	Protocol (SIP)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: -14.6 (--------------)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6


--NextPart


A new Request for Comments is now available in online RFC libraries.


        BCP 98
        RFC 3968

        Title:      The Internet Assigned Number Authority (IANA)
                    Header Field Parameter Registry for
                    the Session Initiation Protocol (SIP)
        Author(s):  G. Camarillo
        Status:     Best Current Practice
        Date:       December 2004
        Mailbox:    Gonzalo.Camarillo@ericsson.com
        Pages:      8
        Characters: 20615
        Updates:    3427
        See Also:   BCP 98

        I-D Tag:    draft-ietf-sip-parameter-registry-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3968.txt


This document creates an Internet Assigned Number Authority (IANA)
registry for the Session Initiation Protocol (SIP) header field
parameters and parameter values.  It also lists the already existing
parameters and parameter values to be used as the initial entries for
this registry.

This document is a product of the Session Initation Protocol Working
Group of the IETF.

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <041221152206.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3968

--OtherAccess
Content-Type: Message/External-body; name="rfc3968.txt"; site="ftp.isi.edu";
	access-type="anon-ftp"; directory="in-notes"

Content-Type: text/plain
Content-ID: <041221152206.RFC@RFC-EDITOR.ORG>


--OtherAccess--
--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--NextPart--



From sip-bounces@ietf.org  Tue Dec 21 19:16:03 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24196
	for <sip-web-archive@ietf.org>; Tue, 21 Dec 2004 19:10:39 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cgu34-0005QD-2z
	for sip-web-archive@ietf.org; Tue, 21 Dec 2004 19:08:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cgtjg-0003Rc-Qk; Tue, 21 Dec 2004 18:48:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgtZH-0007mS-Uv; Tue, 21 Dec 2004 18:37:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20413;
	Tue, 21 Dec 2004 18:37:21 -0500 (EST)
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cgtcf-0002bY-W5; Tue, 21 Dec 2004 18:40:59 -0500
Received: from ISI.EDU (adma.isi.edu [128.9.160.239])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iBLNPAQ25185;
	Tue, 21 Dec 2004 15:25:10 -0800 (PST)
Message-Id: <200412212325.iBLNPAQ25185@boreas.isi.edu>
To: ietf-announce@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 21 Dec 2004 15:25:10 -0800
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: rfc-ed@isi.edu
X-Spam-Score: -14.6 (--------------)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: sip@ietf.org, rfc-editor@rfc-editor.org
Subject: [Sip] BCP 99,
	RFC 3969 on The Internet Assigned Number Authority (IANA)
	Uniform Resource Identifier (URI) Parameter Registry for the
	Session Initiation Protocol (SIP)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: -14.6 (--------------)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6


--NextPart


A new Request for Comments is now available in online RFC libraries.


        BCP 99
        RFC 3969

        Title:      The Internet Assigned Number Authority (IANA)
                    Uniform Resource Identifier (URI) Parameter
                    Registry for the Session Initiation Protocol (SIP)
        Author(s):  G. Camarillo
        Status:     Best Current Practice
        Date:       December 2004
        Mailbox:    Gonzalo.Camarillo@ericsson.com
        Pages:      6
        Characters: 12119
        Updates:    3427
        SeeAlso:    BCP 99

        I-D Tag:    draft-ietf-sip-uri-parameter-reg-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3969.txt


This document creates an Internet Assigned Number Authority (IANA)
registry for the Session Initiation Protocol (SIP) and SIPS Uniform
Resource Identifier (URI) parameters, and their values.  It also lists
the already existing parameters to be used as initial values for that
registry.

This document is a product of the Session Initiation Protocol Working
Group of the IETF.

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <041221152346.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3969

--OtherAccess
Content-Type: Message/External-body; name="rfc3969.txt"; site="ftp.isi.edu";
	access-type="anon-ftp"; directory="in-notes"

Content-Type: text/plain
Content-ID: <041221152346.RFC@RFC-EDITOR.ORG>


--OtherAccess--
--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--NextPart--



From sip-bounces@ietf.org  Tue Dec 21 20:31:21 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01190
	for <sip-web-archive@ietf.org>; Tue, 21 Dec 2004 20:31:21 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgvV5-0003B3-UW
	for sip-web-archive@ietf.org; Tue, 21 Dec 2004 20:41:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CgvHO-0004A0-AV; Tue, 21 Dec 2004 20:27:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CgvDC-0002s3-LV
	for sip@megatron.ietf.org; Tue, 21 Dec 2004 20:22:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00652
	for <sip@ietf.org>; Tue, 21 Dec 2004 20:22:44 -0500 (EST)
Received: from g2.genesyslab.com ([198.49.180.210])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgvMk-0002xn-SB
	for sip@ietf.org; Tue, 21 Dec 2004 20:32:40 -0500
Received: from GIMLI.us.int.genesyslab.com ([192.168.20.233]) by
	g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 21 Dec 2004 17:22:17 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 21 Dec 2004 17:22:07 -0800
Message-ID: <1FB5C49ABD558E4AB7F862303D1E1817028D43@GIMLI.us.int.genesyslab.com>
Thread-Topic: nested 3xx msgs
Thread-Index: AcTnxKUg+TyoqWa0QIGWy5gq2j3DJQ==
From: "Serge Blazhiyevskyy" <sblazhiy@genesyslab.com>
To: <sip@ietf.org>
X-OriginalArrivalTime: 22 Dec 2004 01:22:17.0822 (UTC)
	FILETIME=[AD2CD7E0:01C4E7C4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017
Subject: [Sip] nested 3xx msgs
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1947765730=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34

This is a multi-part message in MIME format.

--===============1947765730==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4E7C4.A6C0B015"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4E7C4.A6C0B015
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
I have a question about 3xx messages.=20
=20
If client initiated a call with INVITE and got 3xx message with 3
destinations, for example.
=20
The first destination returned 3xx msg as well. How client should react
in this case?
=20
Should it forget the first contact header list and try the second one?
Or, should it try both?
=20
Thanks.
Serge

------_=_NextPart_001_01C4E7C4.A6C0B015
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 11">
<meta name=3DOriginator content=3D"Microsoft Word 11">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C4E781.96FD0BE0">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:UseWord2002TableStyleRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" LatentStyleCount=3D"156">
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:#0400;
	mso-fareast-language:#0400;
	mso-bidi-language:#0400;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I have a question about 3xx messages. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If client initiated a call with INVITE and got 3xx =
message
with 3 destinations, for example.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The first destination returned 3xx <span =
class=3DSpellE>msg</span>
as well. How client should react in this =
case?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Should it forget the first contact header list and =
try the
second one? Or, should it try both?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Serge<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C4E7C4.A6C0B015--


--===============1947765730==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1947765730==--



From sip-bounces@ietf.org  Tue Dec 21 21:25:38 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05497
	for <sip-web-archive@ietf.org>; Tue, 21 Dec 2004 21:25:38 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgwLd-0004hf-KD
	for sip-web-archive@ietf.org; Tue, 21 Dec 2004 21:35:34 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cgw0D-0007Zr-SW; Tue, 21 Dec 2004 21:13:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cgvsb-0005rr-4s; Tue, 21 Dec 2004 21:05:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04045;
	Tue, 21 Dec 2004 21:05:30 -0500 (EST)
From: Wayne.Davies@didata.com.au
Received: from nwynmime2.didata.com.au ([148.182.20.110])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cgw27-00047C-F3; Tue, 21 Dec 2004 21:15:26 -0500
Received: from internet.didata.com.au (unverified [148.182.20.65]) by 
	NWYNMIME2.didata.com.au (Content Technologies SMTPRS 4.3.12) with ESMTP
	id <T6e0749d93c94b6146e70c@NWYNMIME2.didata.com.au>; Wed, 22 Dec 2004 
	13:04:42 +1100
To: "Serge Blazhiyevskyy" <sblazhiy@genesyslab.com>,
        sip-implementors@cs.columbia.edu
Subject: Re: [Sip] nested 3xx msgs
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <OFADDDE95E.30B81F08-ONCA256F72.0008D2FC-CA256F72.000B695C@didata.com.au>
Date: Wed, 22 Dec 2004 13:04:39 +1100
X-MIMETrack: Serialize by Router on SYDMTA/Sydney/Com Tech/AU 
	(Release 5.0.11  |July 24, 2002) at 22/12/2004 01:03:52 PM, Serialize 
	complete at 22/12/2004 01:03:52 PM
X-Spam-Score: 0.9 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Cc: sip@ietf.org, sip-bounces@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0183481166=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8

This is a multipart message in MIME format.
--===============0183481166==
Content-Type: multipart/alternative; 
	boundary="=_alternative 000B6959CA256F72_="

This is a multipart message in MIME format.
--=_alternative 000B6959CA256F72_=
Content-Type: text/plain; charset="us-ascii"

Serge,
        Queries on existing SIP usage and behaviour should be sent to the 
SIP Implementors group rather than the SIP IETF WG. Please follow up 
responses to this thread and direct furture queries to the Implementors 
list and not the IETF - thanks.

        In response to the query -  It is my belief in this case that 
because the UA received a response (didn't time out | go unanswered)  and 
it was not a failure response that the new contacts returned in the second 
302 should be tried. If this behaviour continued the result would be that 
the INVITE transaction would eventually time out.

Regards,

Wayne. 
 





"Serge Blazhiyevskyy" <sblazhiy@genesyslab.com>
Sent by: sip-bounces@ietf.org
22/12/2004 12:22 PM

 
        To:     <sip@ietf.org>
        cc: 
        Subject:        [Sip] nested 3xx msgs


Hi,
 
I have a question about 3xx messages. 
 
If client initiated a call with INVITE and got 3xx message with 3 
destinations, for example.
 
The first destination returned 3xx msg as well. How client should react in 
this case?
 
Should it forget the first contact header list and try the second one? Or, 
should it try both?
 
Thanks.
Serge_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



******************************************************************************
 - NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally privileged information.  If you have received this email in error, please notify the sender and delete it immediately.

Internet communications are not secure. You should scan this message and any attachments for viruses.  Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.
******************************************************************************


--=_alternative 000B6959CA256F72_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Serge,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Queries on existing SIP usage and behaviour should be sent to the SIP Implementors group rather than the SIP IETF WG. Please follow up responses to this thread and direct furture queries to the Implementors list and not the IETF - thanks.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; In response to the query - &nbsp;It is my belief in this case that because the UA received a response (didn't time out | go unanswered) &nbsp;and it was not a failure response that the new contacts returned in the second 302 should be tried. If this behaviour continued the result would be that the INVITE transaction would eventually time out.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br>
<br><font size=2 face="sans-serif">Wayne. &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; <br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Serge Blazhiyevskyy&quot; &lt;sblazhiy@genesyslab.com&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: sip-bounces@ietf.org</font>
<p><font size=1 face="sans-serif">22/12/2004 12:22 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&lt;sip@ietf.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;[Sip] nested 3xx msgs</font></table>
<br>
<br>
<br><font size=2 face="Arial">Hi,</font>
<p><font size=2 face="Arial">&nbsp;</font>
<p><font size=2 face="Arial">I have a question about 3xx messages. </font>
<p><font size=2 face="Arial">&nbsp;</font>
<p><font size=2 face="Arial">If client initiated a call with INVITE and got 3xx message with 3 destinations, for example.</font>
<p><font size=2 face="Arial">&nbsp;</font>
<p><font size=2 face="Arial">The first destination returned 3xx msg as well. How client should react in this case?</font>
<p><font size=2 face="Arial">&nbsp;</font>
<p><font size=2 face="Arial">Should it forget the first contact header list and try the second one? Or, should it try both?</font>
<p><font size=2 face="Arial">&nbsp;</font>
<p><font size=2 face="Arial">Thanks.</font>
<p><font size=2 face="Arial">Serge</font><font size=2 face="Courier New">_______________________________________________<br>
Sip mailing list &nbsp;https://www1.ietf.org/mailman/listinfo/sip<br>
This list is for NEW development of the core SIP Protocol<br>
Use sip-implementors@cs.columbia.edu for questions on current sip<br>
Use sipping@ietf.org for new developments on the application of sip</font>
<p>
<p><FONT SIZE=1><BR>
<BR>
******************************************************************************<BR>
 - NOTICE FROM DIMENSION DATA AUSTRALIA<BR>
This message is confidential, and may contain proprietary or legally privileged information.  If you have received this email in error, please notify the sender and delete it immediately.<BR>
<BR>
Internet communications are not secure. You should scan this message and any attachments for viruses.  Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.<BR>
******************************************************************************<BR>
</FONT>

--=_alternative 000B6959CA256F72_=--


--===============0183481166==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0183481166==--



From sip-bounces@ietf.org  Tue Dec 21 23:41:22 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17375
	for <sip-web-archive@ietf.org>; Tue, 21 Dec 2004 23:41:22 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CgyT1-000097-GP
	for sip-web-archive@ietf.org; Tue, 21 Dec 2004 23:51:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cgy9o-0002Z7-5s; Tue, 21 Dec 2004 23:31:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgy5N-0000t6-5N
	for sip@megatron.ietf.org; Tue, 21 Dec 2004 23:26:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16515
	for <sip@ietf.org>; Tue, 21 Dec 2004 23:26:50 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgyEv-0008EX-Ii
	for sip@ietf.org; Tue, 21 Dec 2004 23:36:48 -0500
Received: from rtp-core-2.cisco.com (64.102.124.13)
	by rtp-iport-1.cisco.com with ESMTP; 21 Dec 2004 23:35:22 -0500
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBM4QGgE010162; 
	Tue, 21 Dec 2004 23:26:16 -0500 (EST)
Received: from cisco.com (che-vpn-cluster-2-60.cisco.com [10.86.242.60])
	by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANW83189;
	Tue, 21 Dec 2004 23:26:15 -0500 (EST)
Message-ID: <41C8F767.2010300@cisco.com>
Date: Tue, 21 Dec 2004 23:26:15 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Serge Blazhiyevskyy <sblazhiy@genesyslab.com>
Subject: Re: [Sip] nested 3xx msgs
References: <1FB5C49ABD558E4AB7F862303D1E1817028D43@GIMLI.us.int.genesyslab.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit

Serge,

The client behavior in this case should be comparable to what would 
happen if a proxy handled the redirection. There are not hard and fast 
rules, but I believe current recommended practice (as specified in 
callerprefs - RFC3841) is to order the first set of contacts, and then 
if you get another 3xx from trying one of those, then order them 
subordinate to the position of contact they replace. Whether you serial 
or parallel fork, or some combination, is up to you.

Bottom line - try both sets before giving up.

	Paul

Serge Blazhiyevskyy wrote:
> Hi,
> 
>  
> 
> I have a question about 3xx messages.
> 
>  
> 
> If client initiated a call with INVITE and got 3xx message with 3 
> destinations, for example.
> 
>  
> 
> The first destination returned 3xx msg as well. How client should react 
> in this case?
> 
>  
> 
> Should it forget the first contact header list and try the second one? 
> Or, should it try both?
> 
>  
> 
> Thanks.
> 
> Serge
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec 22 05:16:37 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07692
	for <sip-web-archive@ietf.org>; Wed, 22 Dec 2004 05:16:36 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ch3hV-0000Mj-Ml
	for sip-web-archive@ietf.org; Wed, 22 Dec 2004 05:26:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ch3TP-0007Tn-Kt; Wed, 22 Dec 2004 05:12:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch3Sm-0007Cb-G3
	for sip@megatron.ietf.org; Wed, 22 Dec 2004 05:11:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07264
	for <sip@ietf.org>; Wed, 22 Dec 2004 05:11:21 -0500 (EST)
Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch3cM-0000EO-5S
	for sip@ietf.org; Wed, 22 Dec 2004 05:21:23 -0500
Received: from Nataraju (dex@[192.168.2.115])
	by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id
	iBMA9fo05113; Wed, 22 Dec 2004 15:39:42 +0530
From: "Nataraju A B" <bnataraju@kodiaknetworks.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>,
        "'Serge Blazhiyevskyy'" <sblazhiy@genesyslab.com>
Subject: RE: [Sip] nested 3xx msgs
Date: Wed, 22 Dec 2004 15:34:46 +0530
Message-ID: <001701c4e80d$ab53ef00$7302a8c0@Nataraju>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <41C8F767.2010300@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Content-Transfer-Encoding: 7bit

Comments inline...

Best Regards,
Nataraju A.B.
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Paul Kyzivat
Sent: Wednesday, December 22, 2004 9:56 AM
To: Serge Blazhiyevskyy
Cc: sip@ietf.org
Subject: Re: [Sip] nested 3xx msgs

Serge,

The client behavior in this case should be comparable to what would 
happen if a proxy handled the redirection. There are not hard and fast 
rules, but I believe current recommended practice (as specified in 
callerprefs - RFC3841) is to order the first set of contacts, and then 
if you get another 3xx from trying one of those, then order them 
subordinate to the position of contact they replace. Whether you serial 
or parallel fork, or some combination, is up to you.

Bottom line - try both sets before giving up.

[ABN] but don't repeat on any contacts received in multiple 3xx
responses...

	Paul

Serge Blazhiyevskyy wrote:
> Hi,
> 
>  
> 
> I have a question about 3xx messages.
> 
>  
> 
> If client initiated a call with INVITE and got 3xx message with 3 
> destinations, for example.
> 
>  
> 
> The first destination returned 3xx msg as well. How client should
react 
> in this case?
> 
>  
> 
> Should it forget the first contact header list and try the second one?

> Or, should it try both?
> 
>  
> 
> Thanks.
> 
> Serge
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec 22 12:22:32 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14908
	for <sip-web-archive@ietf.org>; Wed, 22 Dec 2004 12:22:32 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1ChALZ-0005CP-Dx
	for sip-web-archive@ietf.org; Wed, 22 Dec 2004 12:32:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ch9wq-0005Ro-UP; Wed, 22 Dec 2004 12:06:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ch9jM-0000kO-I9
	for sip@megatron.ietf.org; Wed, 22 Dec 2004 11:52:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12208
	for <sip@ietf.org>; Wed, 22 Dec 2004 11:52:53 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch9t3-0004Gr-Ta
	for sip@ietf.org; Wed, 22 Dec 2004 12:02:58 -0500
Received: from [64.101.149.107] ([64.101.149.107]) (authenticated bits=0)
	by nylon.softarmor.com (8.12.11/8.12.11) with ESMTP id iBMGrgV8006124
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Wed, 22 Dec 2004 10:53:43 -0600
In-Reply-To: <135d813a7c.13a7c135d8@bnuep.com>
References: <135d813a7c.13a7c135d8@bnuep.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E3F7D3A6-5439-11D9-B3DA-000D93594350@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] About 403 Forbidden
Date: Wed, 22 Dec 2004 10:52:39 -0600
To: wangy@bnuep.com
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit


On Dec 19, 2004, at 11:29 PM, wangy@bnuep.com wrote:

> When I reading the RFC 3261, about 403 Forbidden description as 
> following
> -----------------------------------------------------------------------
> 7.4.4 403 Forbidden
>
>    The server understood the request, but is refusing to fulfill it.
>    Authorization will not help, and the request SHOULD NOT be repeated.
> ----------------------------------------------------------------------
>> From above description, what is the request? From my view,I think 
>> that "the request" is Client. right or not? BTW, if yes, how to 
>> understand the sentence of "the request SHOULD NOT be repeated"
>>

UAC (User Agent Clients) originate requests, and UAS (User Agent 
Servers) respond to requests.

The phrase "the request" here refers to the SIP request message, such 
as INVITE, REGISTER, OPTIONS, NOTIFY, BYE, etc. that the UAS is 
responding to with a 403.

In short, if UA-1 sends an INVITE to UA-2 and UA-2 replies with a 403, 
then UA-1 should NOT retry the same INVITE.

--
dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec 22 22:40:17 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14712
	for <sip-web-archive@ietf.org>; Wed, 22 Dec 2004 22:40:17 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1ChJzg-00053r-9s
	for sip-web-archive@ietf.org; Wed, 22 Dec 2004 22:50:28 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ChJkj-0001g9-KB; Wed, 22 Dec 2004 22:35:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ChJjF-0001IG-UU
	for sip@megatron.ietf.org; Wed, 22 Dec 2004 22:33:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14338
	for <sip@ietf.org>; Wed, 22 Dec 2004 22:33:27 -0500 (EST)
Received: from junkmail.cs.umd.edu ([128.8.128.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChJsy-0004t5-Tc
	for sip@ietf.org; Wed, 22 Dec 2004 22:43:38 -0500
Received: from utz.cs.umd.edu (utz.cs.umd.edu [128.8.129.122])
	by junkmail.cs.umd.edu (8.12.10/8.12.5) with ESMTP id iBN3WsFs008237
	for <sip@ietf.org>; Wed, 22 Dec 2004 22:32:54 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by utz.cs.umd.edu (8.12.11/8.12.5) with ESMTP id iBN3WsSY011731
	for <sip@ietf.org>; Wed, 22 Dec 2004 22:32:54 -0500
Date: Wed, 22 Dec 2004 22:32:54 -0500 (EST)
From: "Moustafa A. Youssef" <moustafa@cs.umd.edu>
To: sip@ietf.org
Message-ID: <Pine.LNX.4.58.0412222232170.11326@utz.cs.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Subject: [Sip] CFP:  IEEE WirelessCom Symposium on Mobile Computing, 2005
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86

(Our apologies if you receive multiple copies of this CFP)

-------------------------------------------------------------
                Call for Papers
           Symposium on Mobile Computing
  http://www.csee.umbc.edu/~younis/WC_MobCom05.htm
                  as part of
             IEEE WirelessCom 2005
Sheraton Maui Resort, Kaanapali Beach, Maui, Hawaii, USA
http://www.ece.queensu.ca/hpages/faculty/safwat/wirelesscom/05/
                 June 13-16, 2005
  Technical Sponsorship: IEEE TCCC, TCPC, and SSCTC


Recent years have witnessed an enormous growth in the development
and applications of mobile computing environments and devices.
Many practitioners envision a future empowered with context and
location aware computation and communication infrastructure that
allow users to access data and receive service at any place and
any time. Compared to conventional platforms, the mobility of
computing nodes introduces many challenges to the design of almost
all systems components.

This symposium will foster a forum for discussing and presenting
recent research results on mobile computer systems. Original
papers are invited in the broader area of mobile computing. Papers
must report high-quality and previously unpublished work. Topics
of interest include, but are not limited to, the following:

-  Architecture and infrastructure support
-  Middleware and operating systems services
-  Development platforms and environments
-  Adaptive resource management schemes
-  Pervasive and Context-aware Computing
-  Performance metrics and studies
-  Power aware computation and communication
-  Data consistency and synchronization protocols
-  Fault-tolerant architectural and operation models
-  Wearable computing devices and systems
-  Time constrained mobile systems
-  Robust ad-hoc networking techniques
-  Efficient localization techniques
-  Wireless sensor networks
-  Mobile peer to peer systems
-  Quality of service provisioning
-  Context-conscious computing
-  Web caching and services
-  Emerging applications and systems
-  Mobile agents
-  Mobile commerce
-  Security and privacy issues


Submission Guidelines
---------------------
Prospective authors should submit their paper electronically to
younis@csee.umbc.edu.  All papers are limited to 6 pages in MS-Word, PS
or PDF using standard IEEE double-column format. The first page should
include title, authors' contact information, an abstract and five
keywords. Authors should attach the paper abstract to their message.

Important Dates
---------------
Paper Submission Deadline:      March 15, 2005
Notification of Acceptance:     April 15, 2005
Camera-Ready Papers:            May 1, 2005

Symposium Co-Chairs
-------------------
Mohamed Younis
Department of Computer Science and Electrical Engineering
University of Maryland Baltimore County,
E-mail: younis@csee.umbc.edu

Hesham El-Rewini
Department of Computer Science and Engineering
Southern Methodist University
E-mail: rewini@engr.smu.edu


Publicity Chair
----------------
Moustafa Youssef
Department of Computer Science
University of Maryland at College Park,
E-mail: moustafa@cs.umd.edu



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec 23 13:57:48 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08020
	for <sip-web-archive@ietf.org>; Thu, 23 Dec 2004 13:57:48 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1ChYJJ-00045O-Q0
	for sip-web-archive@ietf.org; Thu, 23 Dec 2004 14:08:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ChY0k-0004h9-US; Thu, 23 Dec 2004 13:48:30 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ChXoz-0001CK-NZ
	for sip@megatron.ietf.org; Thu, 23 Dec 2004 13:36:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06410
	for <sip@ietf.org>; Thu, 23 Dec 2004 13:36:18 -0500 (EST)
Received: from ausmtp02.au.ibm.com ([202.81.18.187])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChXyt-0003Uh-VQ
	for sip@ietf.org; Thu, 23 Dec 2004 13:46:37 -0500
Received: from sd0112e0.au.ibm.com (d23rh903.au.ibm.com [202.81.18.201])
	by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id iBNIXO08171044
	for <sip@ietf.org>; Fri, 24 Dec 2004 05:33:24 +1100
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.250.242])
	by sd0112e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id
	iBNIbiAg199990 for <sip@ietf.org>; Fri, 24 Dec 2004 05:37:44 +1100
Received: from d23av01.au.ibm.com (loopback [127.0.0.1])
	by d23av01.au.ibm.com (8.12.11/8.12.11) with ESMTP id iBNIZlSg031352
	for <sip@ietf.org>; Fri, 24 Dec 2004 05:35:47 +1100
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.181.2.75])
	by d23av01.au.ibm.com (8.12.11/8.12.11) with ESMTP id iBNIZkxG031347
	for <sip@ietf.org>; Fri, 24 Dec 2004 05:35:46 +1100
From: Xin Sheng Mao <maoxs@cn.ibm.com>
To: sip@ietf.org
Message-ID: <OF241BB114.5DD47CD6-ON48256F73.0065E83C-48256F73.0065E83C@cn.ibm.com>
Date: Fri, 24 Dec 2004 02:33:05 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 6.51HF338 | June
	21, 2004) at 24/12/2004 02:33:07
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: [Sip] Xin Sheng Mao/China/IBM is out of the office.
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0697076657=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9

--===============0697076657==
Content-type: multipart/alternative; 
	Boundary="0__=C7BBE5E0DFF66EAC8f9e8a93df938690918cC7BBE5E0DFF66EAC"
Content-Disposition: inline

--0__=C7BBE5E0DFF66EAC8f9e8a93df938690918cC7BBE5E0DFF66EAC
Content-type: text/plain; charset=US-ASCII





I will be out of the office starting  2004-12-24 and will not return until
2005-01-03.

I am out of office from December 24, and will not come back till January 3.
Please access me at 13501183394 if you have any urgency.
--0__=C7BBE5E0DFF66EAC8f9e8a93df938690918cC7BBE5E0DFF66EAC
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline

<html><body>
<p>I will be out of the office starting  2004-12-24 and will not return until 2005-01-03.<br>
<br>
I am out of office from December 24, and will not come back till January 3. Please access me at 13501183394 if you have any urgency.</body></html>
--0__=C7BBE5E0DFF66EAC8f9e8a93df938690918cC7BBE5E0DFF66EAC--



--===============0697076657==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============0697076657==--




From sip-bounces@ietf.org  Thu Dec 23 15:25:41 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17445
	for <sip-web-archive@ietf.org>; Thu, 23 Dec 2004 15:25:40 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1ChZgl-0006M5-SH
	for sip-web-archive@ietf.org; Thu, 23 Dec 2004 15:36:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ChZNx-0004lN-Fy; Thu, 23 Dec 2004 15:16:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ChZJ9-0001Qw-Va
	for sip@megatron.ietf.org; Thu, 23 Dec 2004 15:11:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15718
	for <sip@ietf.org>; Thu, 23 Dec 2004 15:11:33 -0500 (EST)
Received: from airwolf.sentito.com ([65.202.222.11])
	by ietf-mx.ietf.org with smtp (Exim 4.33) id 1ChZT6-00060K-CB
	for sip@ietf.org; Thu, 23 Dec 2004 15:21:52 -0500
Received: (qmail 59348 invoked by uid 1014); 23 Dec 2004 20:10:52 -0000
Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with
	qmail-scanner-1.22 
	(clamdscan: 0.80. spamassassin: 2.63.   Clear:RC:1(65.202.222.2):. 
	Processed in 0.298949 secs); 23 Dec 2004 20:10:52 -0000
Received: from unknown (HELO SAJAK) (65.202.222.2)
	by airwolf.sentito.com with SMTP; 23 Dec 2004 20:10:51 -0000
From: "Shan Lu" <shanlu@sentito.com>
To: "'Brett Tate'" <brett@broadsoft.com>, "'sip-ietf'" <sip@ietf.org>
Subject: RE: [Sip] RFC 3261: 32 bit CSeq number
Date: Thu, 23 Dec 2004 15:12:17 -0500
Message-ID: <00ce01c4e92b$b3fd1630$eb00000a@SAJAK>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <001701c4de18$059a82d0$a601a8c0@brett1>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit

Brett,

But Section 8.1.1.5 does apply to in-dialog request -- for the side that
acted as UAS in dialog creation. 

12.2.1.1/RFC2161

"If the local sequence number is empty, an initial value MUST be chosen
using the guidelines of Section 8.1.1.5."

Did I miss something?

Thanks, Shan Lu 

>-----Original Message-----
>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On 
>Behalf Of Brett Tate
>Sent: Thursday, December 09, 2004 12:54 PM
>To: sip-ietf
>Subject: [Sip] RFC 3261: 32 bit CSeq number
>
>
>
>I have recently observed that some vendors are reading RFC 3261 section
>8.1.1.5's CSeq maximum value comments out of context.  They 
>are interpreting
>the statement to also apply to requests within dialogs.  They are not
>noticing the text within sections 8 and 8.1 which indicate that these
>subsections apply to requests outside of a dialog.  Is it 
>possible to get
>the sentence reworded for clarity within errata and/or a future bis?
>
>RFC 3261 section 8.1.1.5:
>"The sequence number value MUST be expressible as a 32-bit 
>unsigned integer
>and MUST be less than 2**31."
>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec 23 22:12:30 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22805
	for <sip-web-archive@ietf.org>; Thu, 23 Dec 2004 22:12:29 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Chg2W-0008KV-QK
	for sip-web-archive@ietf.org; Thu, 23 Dec 2004 22:22:53 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ChfnK-0004N2-LG; Thu, 23 Dec 2004 22:07:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Chfk3-0003Pl-Vf
	for sip@megatron.ietf.org; Thu, 23 Dec 2004 22:03:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22335
	for <sip@ietf.org>; Thu, 23 Dec 2004 22:03:45 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Chfu4-0008B4-2Y for sip@ietf.org; Thu, 23 Dec 2004 22:14:08 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 23 Dec 2004 20:11:39 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBO33Ao9016529;
	Thu, 23 Dec 2004 19:03:10 -0800 (PST)
Received: from [192.168.1.102] (sjc-vpn1-331.cisco.com [10.21.97.75])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUZ78916;
	Thu, 23 Dec 2004 19:03:12 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Wed, 22 Dec 2004 07:57:16 -0800
Subject: Re: [Sip] a question about the tag in From or To header
From: Cullen Jennings <fluffy@cisco.com>
To: "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com>, "sip@ietf.org" <sip@ietf.org>
Message-ID: <BDEED95C.202A2%fluffy@cisco.com>
In-Reply-To: <11FD90E74279C0489ECB6793F227C847044BFBDE@idc1exc0002.corp.global.level3.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: 7bit


It seems that 
 
   Similarly, two INVITEs for different calls will
   have different From tags, and two responses for different calls will
   have different To tags."

is pretty clear that you need to do Interpretation 2. Is there some problem
with this and reason why you want to do 1?



On 12/17/04 11:34 AM, "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com> wrote:

> We have a debate on how to interpret the following paragraph (RFC 3261,
> section 19.3):
> 
> ===========
> 19.3 Tags
>    ...
> 
>    When a tag is generated by a UA for insertion into a request or
>    response, it MUST be globally unique and cryptographically random
>    with at least 32 bits of randomness.  A property of this selection
>    requirement is that a UA will place a different tag into the From
>    header of an INVITE than it would place into the To header of the
>    response to the same INVITE.  This is needed in order for a UA to
>    invite itself to a session, a common case for "hairpinning" of calls
>    in PSTN gateways.  Similarly, two INVITEs for different calls will
>    have different From tags, and two responses for different calls will
>    have different To tags.
> 
>    ...
> ===========
> 
> Interpretation 1: A tag needs to be globally unique across space (aka UAs) but
> not across time because Call-ID (section 8.1.1.4) is already unique across
> space and time for calls. So a same UAC can use a same >From tag in different
> calls it imitates. And a same UAS can use a same To tag to respond to
> different calls. A same UA uses different tags in >From and To headers.
> Different UAs use different tags.
> 
> Interpretation 2: A tag needs to be different for each call. So a same UAC has
> to use two different tags in From header when it initiates two different
> calls. And a same UAS has to use different tags in To headers for different
> calls. 
> 
> We would like to hear from the list which way we should interpret the above
> paragraph or what is the right interpretation if both interpretations are not
> accurate.
> 
> Thanks.
> 
> 
> Jin-Gen Wang
> Level3 Communications, Inc.
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec 23 22:19:01 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23278
	for <sip-web-archive@ietf.org>; Thu, 23 Dec 2004 22:19:00 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Chg8o-0008UD-Tl
	for sip-web-archive@ietf.org; Thu, 23 Dec 2004 22:29:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ChfnO-0004NH-Dn; Thu, 23 Dec 2004 22:07:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Chfk5-0003Pp-5O
	for sip@megatron.ietf.org; Thu, 23 Dec 2004 22:03:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22343
	for <sip@ietf.org>; Thu, 23 Dec 2004 22:03:46 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Chfu5-0008B4-Cj for sip@ietf.org; Thu, 23 Dec 2004 22:14:09 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 23 Dec 2004 20:11:42 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBO33AoB016529;
	Thu, 23 Dec 2004 19:03:12 -0800 (PST)
Received: from [192.168.1.102] (sjc-vpn1-331.cisco.com [10.21.97.75])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUZ78918;
	Thu, 23 Dec 2004 19:03:13 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Wed, 22 Dec 2004 07:59:08 -0800
Subject: Re: [Sip] (no subject)
From: Cullen Jennings <fluffy@cisco.com>
To: liuyang <liuyang5599@163.com>,
        "sip-implementors@cs.columbia.edu" <sip-implementors@cs.columbia.edu>
Message-ID: <BDEED9CC.202A3%fluffy@cisco.com>
In-Reply-To: <200412171344.IAA18314@ietf.org>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Adam Roach <adam@nostrum.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit


I'm not aware of any but the sip-implementors list (I CC'd it here) would
probably be a better place to ask this.

People replying to this, please remove the sip@ietf.org


On 12/17/04 5:48 AM, "liuyang" <liuyang5599@163.com> wrote:

> Merry christmas.
>      Inow i am working on a b project about sip
>  compression,but i am a beginer in this field,i wanna ask you
>  a question: is there any open source project on SIP compression and
>  where 
>  can i find it?
>   
>    your reply will help us a lot ?
> 
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec 23 22:20:59 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23440
	for <sip-web-archive@ietf.org>; Thu, 23 Dec 2004 22:20:59 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1ChgAj-00006f-O5
	for sip-web-archive@ietf.org; Thu, 23 Dec 2004 22:31:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ChfnP-0004OG-Q8; Thu, 23 Dec 2004 22:07:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Chfk5-0003Pr-QD
	for sip@megatron.ietf.org; Thu, 23 Dec 2004 22:03:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22346
	for <sip@ietf.org>; Thu, 23 Dec 2004 22:03:47 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Chfu5-0008B4-TL for sip@ietf.org; Thu, 23 Dec 2004 22:14:10 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-3.cisco.com with ESMTP; 23 Dec 2004 20:11:45 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBO33FHn021553;
	Thu, 23 Dec 2004 19:03:15 -0800 (PST)
Received: from [192.168.1.102] (sjc-vpn1-331.cisco.com [10.21.97.75])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUZ78920;
	Thu, 23 Dec 2004 19:03:14 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Wed, 22 Dec 2004 08:02:47 -0800
Subject: Re: [Sip] target topology in connect-reuse
From: Cullen Jennings <fluffy@cisco.com>
To: Robert Sanders <rsanders@gmail.com>, "sip@ietf.org" <sip@ietf.org>
Message-ID: <BDEEDAA7.202A4%fluffy@cisco.com>
In-Reply-To: <373517a1041215093633906525@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit


Makes sense - you might want to start pushing this a little because right
now, I am not aware of a single SIP product that supports it. I would
initially encourage UA to at least send the option. That way there will be
UA in place that support when people finally do upgrade to proxies that
support it. 


On 12/15/04 9:36 AM, "Robert Sanders" <rsanders@gmail.com> wrote:

> On Wed, 15 Dec 2004 09:31:07 -0700, Cullen Jennings <fluffy@cisco.com> wrote:
> 
>> Yes. I was assuming more 2 than 1 - we are trying to get this into SIP stuff
>> but I don't believe anyone has implemented it yet. I think the wildcards are
>> forbitten in sip but multi-name are allowed. I'm not sure if anyone will use
>> them.
> 
> We have well over 300,000 hosted domains at EarthLink, and around 150
> domains in our consumer service.  We absolutely must use the
> server_name extension.  I can't imagine us doing TLS without it.  We
> might *also* want multi-name, as we currently allow people to use URIs
> of the form <user>@sip.<domain> as aliases for <name>@<domain>, where
> sip.<domain> has an A record for the proxy for <domain>.  This is
> primariy for working around proxies that don't support SRV.  But
> multi-name is clearly neither necessary if there is mandatory support
> for server_name, nor a sufficient replacement for it.
> 
> regards,
>   -- Robert
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec 23 22:22:56 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23814
	for <sip-web-archive@ietf.org>; Thu, 23 Dec 2004 22:22:55 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1ChgCb-0000E5-UF
	for sip-web-archive@ietf.org; Thu, 23 Dec 2004 22:33:19 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ChfnR-0004Oq-Uu; Thu, 23 Dec 2004 22:07:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Chfk6-0003Pw-Vw
	for sip@megatron.ietf.org; Thu, 23 Dec 2004 22:03:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22358
	for <sip@ietf.org>; Thu, 23 Dec 2004 22:03:48 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Chfu6-0008B5-5u for sip@ietf.org; Thu, 23 Dec 2004 22:14:11 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-2.cisco.com with ESMTP; 23 Dec 2004 19:09:01 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBO33EdP014413;
	Thu, 23 Dec 2004 19:03:14 -0800 (PST)
Received: from [192.168.1.102] (sjc-vpn1-331.cisco.com [10.21.97.75])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUZ78922;
	Thu, 23 Dec 2004 19:03:15 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Wed, 22 Dec 2004 08:08:05 -0800
Subject: Re: [Sip] refer-with-norefersub
From: Cullen Jennings <fluffy@cisco.com>
To: Adam Roach <adam@nostrum.com>
Message-ID: <BDEEDBE5.202A6%fluffy@cisco.com>
In-Reply-To: <41C0AC11.5080208@nostrum.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Orit Levin <oritl@microsoft.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit


Yes - I have seen the errors in my ways :-) You are right.
 
On 12/15/04 1:26 PM, "Adam Roach" <adam@nostrum.com> wrote:

> Cullen Jennings wrote:
> 
>> I think I understand that often the subscriptions is of no use and what you
>> want to do here.
>> 
>> It seems like putting a tag in the uri of the refer like ";norefersub" could
>> be used as a hint not to create the implicit subscription. It does not seem
>> like the Supported Require stuff is needed.
>> 
>> Would this work and do what you want?
>>  
>> 
> 
> This seems wrong to me -- largely because you're saying that, for
> certain URIs, based on local policy decisions, we are supposed to ignore
> MUST-strength normative statements of RFC3515 (e.g. "The NOTIFY
> mechanism defined in [2] MUST be used to inform the agent sending the
> REFER of the status of the reference.")
> 
> It seems very much to me that changing behavior to be noncompliant with
> an RFC requires another RFC.
> 
> I could easily formulate scenarios where this proposal actually causes
> interoperability issues, but I believe that the objection on principle
> is sufficiently strong that it's not worth wasting anyone's time
> outlining the practical problems.
> 
> /a
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec 23 23:46:14 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29822
	for <sip-web-archive@ietf.org>; Thu, 23 Dec 2004 23:46:14 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1ChhVF-0001jJ-Cl
	for sip-web-archive@ietf.org; Thu, 23 Dec 2004 23:56:39 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ChhJj-0004TU-FJ; Thu, 23 Dec 2004 23:44:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ChhGX-0003qQ-55
	for sip@megatron.ietf.org; Thu, 23 Dec 2004 23:41:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29447
	for <sip@ietf.org>; Thu, 23 Dec 2004 23:41:21 -0500 (EST)
Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChhQS-0001eg-Ur
	for sip@ietf.org; Thu, 23 Dec 2004 23:51:46 -0500
Received: from Nataraju ([192.168.2.115])
	by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id
	iBO4cVo17477; Fri, 24 Dec 2004 10:08:32 +0530
From: "Nataraju A B" <bnataraju@kodiaknetworks.com>
To: "'Cullen Jennings'" <fluffy@cisco.com>,
        "'Wang, Jin-Gen'" <Jin-Gen.Wang@Level3.com>, <sip@ietf.org>
Subject: RE: [Sip] a question about the tag in From or To header
Date: Fri, 24 Dec 2004 10:03:35 +0530
Message-ID: <000d01c4e971$bda6d4a0$7302a8c0@Nataraju>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <BDEED95C.202A2%fluffy@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Content-Transfer-Encoding: 7bit
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Content-Transfer-Encoding: 7bit

Comments inline...

Best Regards,
Nataraju A.B.
Kodiak Networks Ind Pvt Ltd.,
Phone : +91 80 2222 7960 Xtn 555

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Cullen Jennings
Sent: Wednesday, December 22, 2004 9:27 PM
To: Wang, Jin-Gen; sip@ietf.org
Subject: Re: [Sip] a question about the tag in From or To header


It seems that 
 
   Similarly, two INVITEs for different calls will
   have different From tags, and two responses for different calls will
   have different To tags."

is pretty clear that you need to do Interpretation 2. Is there some
problem
with this and reason why you want to do 1?

[ABN] the option 1 would be preferred to have simplicity in identifying
the user from the from-tag itself....(that is an implementation issue
only)

On 12/17/04 11:34 AM, "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com> wrote:

> We have a debate on how to interpret the following paragraph (RFC
3261,
> section 19.3):
> 
> ===========
> 19.3 Tags
>    ...
> 
>    When a tag is generated by a UA for insertion into a request or
>    response, it MUST be globally unique and cryptographically random
>    with at least 32 bits of randomness.  A property of this selection
>    requirement is that a UA will place a different tag into the From
>    header of an INVITE than it would place into the To header of the
>    response to the same INVITE.  This is needed in order for a UA to
>    invite itself to a session, a common case for "hairpinning" of
calls
>    in PSTN gateways.  Similarly, two INVITEs for different calls will
>    have different From tags, and two responses for different calls
will
>    have different To tags.
> 
>    ...
> ===========
> 
> Interpretation 1: A tag needs to be globally unique across space (aka
UAs) but
> not across time because Call-ID (section 8.1.1.4) is already unique
across
> space and time for calls. So a same UAC can use a same >From tag in
different
> calls it imitates. And a same UAS can use a same To tag to respond to
> different calls. A same UA uses different tags in >From and To
headers.
> Different UAs use different tags.
> 
> Interpretation 2: A tag needs to be different for each call. So a same
UAC has
> to use two different tags in From header when it initiates two
different
> calls. And a same UAS has to use different tags in To headers for
different
> calls. 
> 
> We would like to hear from the list which way we should interpret the
above
> paragraph or what is the right interpretation if both interpretations
are not
> accurate.
> 
> Thanks.
> 
> 
> Jin-Gen Wang
> Level3 Communications, Inc.
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Fri Dec 24 00:39:24 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03120
	for <sip-web-archive@ietf.org>; Fri, 24 Dec 2004 00:39:24 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1ChiKj-0002hq-NM
	for sip-web-archive@ietf.org; Fri, 24 Dec 2004 00:49:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Chi6U-0001zG-Po; Fri, 24 Dec 2004 00:35:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Chi4O-0001LE-G7
	for sip@megatron.ietf.org; Fri, 24 Dec 2004 00:32:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02794
	for <sip@ietf.org>; Fri, 24 Dec 2004 00:32:53 -0500 (EST)
Received: from machine77.level3.com ([209.244.4.106] helo=scanner3.l3.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChiEP-0002be-VF
	for sip@ietf.org; Fri, 24 Dec 2004 00:43:18 -0500
Received: from scanner3.l3.com (localhost [127.0.0.1])
	by localhost.l3.com (Postfix) with ESMTP
	id 06FD178BFF1; Fri, 24 Dec 2004 05:32:25 +0000 (GMT)
Received: from idc1exc0001.corp.global.level3.com
	(idc1exc0001.corp.global.level3.com [10.1.7.194])
	by scanner3.l3.com (Postfix) with SMTP
	id 937D178B577; Fri, 24 Dec 2004 05:32:24 +0000 (GMT)
Received: from idc1exc0002.corp.global.level3.com ([10.1.8.18]) by
	idc1exc0001.corp.global.level3.com with Microsoft
	SMTPSVC(6.0.3790.211); Thu, 23 Dec 2004 22:32:24 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] a question about the tag in From or To header
Date: Thu, 23 Dec 2004 22:32:23 -0700
Message-ID: <11FD90E74279C0489ECB6793F227C847044BFC18@idc1exc0002.corp.global.level3.com>
Thread-Topic: [Sip] a question about the tag in From or To header
Thread-Index: AcTpcrl4PYYN1aqLSlC0mm0D/oyNTwABQZBQ
From: "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com>
To: "Nataraju A B" <bnataraju@kodiaknetworks.com>,
        "Cullen Jennings" <fluffy@cisco.com>, <sip@ietf.org>
X-OriginalArrivalTime: 24 Dec 2004 05:32:24.0395 (UTC)
	FILETIME=[F29DA9B0:01C4E979]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Content-Transfer-Encoding: quoted-printable
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Content-Transfer-Encoding: quoted-printable

Thanks for your reply. The From tag, Call-ID, and To tag are used to =
identify a dialog. Since Call-ID is already unique across time and =
space, it seems that it is sufficient the tags in From and To headers =
only need to be unique across space. Like ABN mentioned, interpretation =
1 leads to a simpler implementation. Our question is: does =
interpretation 1 violate RFC 3261?

Thanks.

Jin-Gen Wang
Level3 Communications, Inc.

-----Original Message-----
From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com]
Sent: Thursday, December 23, 2004 9:34 PM
To: 'Cullen Jennings'; Wang, Jin-Gen; sip@ietf.org
Subject: RE: [Sip] a question about the tag in From or To header


Comments inline...

Best Regards,
Nataraju A.B.
Kodiak Networks Ind Pvt Ltd.,
Phone : +91 80 2222 7960 Xtn 555

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Cullen Jennings
Sent: Wednesday, December 22, 2004 9:27 PM
To: Wang, Jin-Gen; sip@ietf.org
Subject: Re: [Sip] a question about the tag in From or To header


It seems that=20
=20
   Similarly, two INVITEs for different calls will
   have different From tags, and two responses for different calls will
   have different To tags."

is pretty clear that you need to do Interpretation 2. Is there some
problem
with this and reason why you want to do 1?

[ABN] the option 1 would be preferred to have simplicity in identifying
the user from the from-tag itself....(that is an implementation issue
only)

On 12/17/04 11:34 AM, "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com> wrote:

> We have a debate on how to interpret the following paragraph (RFC
3261,
> section 19.3):
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 19.3 Tags
>    ...
>=20
>    When a tag is generated by a UA for insertion into a request or
>    response, it MUST be globally unique and cryptographically random
>    with at least 32 bits of randomness.  A property of this selection
>    requirement is that a UA will place a different tag into the From
>    header of an INVITE than it would place into the To header of the
>    response to the same INVITE.  This is needed in order for a UA to
>    invite itself to a session, a common case for "hairpinning" of
calls
>    in PSTN gateways.  Similarly, two INVITEs for different calls will
>    have different From tags, and two responses for different calls
will
>    have different To tags.
>=20
>    ...
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Interpretation 1: A tag needs to be globally unique across space (aka
UAs) but
> not across time because Call-ID (section 8.1.1.4) is already unique
across
> space and time for calls. So a same UAC can use a same >From tag in
different
> calls it imitates. And a same UAS can use a same To tag to respond to
> different calls. A same UA uses different tags in >From and To
headers.
> Different UAs use different tags.
>=20
> Interpretation 2: A tag needs to be different for each call. So a same
UAC has
> to use two different tags in From header when it initiates two
different
> calls. And a same UAS has to use different tags in To headers for
different
> calls.=20
>=20
> We would like to hear from the list which way we should interpret the
above
> paragraph or what is the right interpretation if both interpretations
are not
> accurate.
>=20
> Thanks.
>=20
>=20
> Jin-Gen Wang
> Level3 Communications, Inc.
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Fri Dec 24 02:25:50 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23328
	for <sip-web-archive@ietf.org>; Fri, 24 Dec 2004 02:25:50 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Chjzi-0004Uf-Vn
	for sip-web-archive@ietf.org; Fri, 24 Dec 2004 02:36:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Chjko-0002VE-Ko; Fri, 24 Dec 2004 02:20:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ChjiO-0000xP-Bl
	for sip@megatron.ietf.org; Fri, 24 Dec 2004 02:18:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22496
	for <sip@ietf.org>; Fri, 24 Dec 2004 02:18:18 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChjsQ-0004Mn-Ik
	for sip@ietf.org; Fri, 24 Dec 2004 02:28:43 -0500
Received: from [192.168.0.108] (adsl-209-30-64-8.dsl.rcsntx.swbell.net
	[209.30.64.8]) (authenticated bits=0)
	by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iBO7HY2X079920
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 24 Dec 2004 01:17:36 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <41CBC28B.5040205@nostrum.com>
Date: Fri, 24 Dec 2004 01:17:31 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com>
Subject: Re: [Sip] a question about the tag in From or To header
References: <11FD90E74279C0489ECB6793F227C847044BFC18@idc1exc0002.corp.global.level3.com>
In-Reply-To: <11FD90E74279C0489ECB6793F227C847044BFC18@idc1exc0002.corp.global.level3.com>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783
Content-Transfer-Encoding: 7bit

Wang, Jin-Gen wrote:

>Thanks for your reply. The From tag, Call-ID, and To tag are used to identify a dialog. Since Call-ID is already unique across time and space, it seems that it is sufficient the tags in From and To headers only need to be unique across space. Like ABN mentioned, interpretation 1 leads to a simpler implementation. Our question is: does interpretation 1 violate RFC 3261?
>  
>

Yes, it does. The text Cullen pointed out *comes* *from* RFC 3261. It 
basically says that intrepretation 1 is wrong.

/a


>Thanks.
>
>Jin-Gen Wang
>Level3 Communications, Inc.
>
>-----Original Message-----
>From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com]
>Sent: Thursday, December 23, 2004 9:34 PM
>To: 'Cullen Jennings'; Wang, Jin-Gen; sip@ietf.org
>Subject: RE: [Sip] a question about the tag in From or To header
>
>
>Comments inline...
>
>Best Regards,
>Nataraju A.B.
>Kodiak Networks Ind Pvt Ltd.,
>Phone : +91 80 2222 7960 Xtn 555
>
>-----Original Message-----
>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
>Cullen Jennings
>Sent: Wednesday, December 22, 2004 9:27 PM
>To: Wang, Jin-Gen; sip@ietf.org
>Subject: Re: [Sip] a question about the tag in From or To header
>
>
>It seems that 
> 
>   Similarly, two INVITEs for different calls will
>   have different From tags, and two responses for different calls will
>   have different To tags."
>
>is pretty clear that you need to do Interpretation 2. Is there some
>problem
>with this and reason why you want to do 1?
>
>[ABN] the option 1 would be preferred to have simplicity in identifying
>the user from the from-tag itself....(that is an implementation issue
>only)
>
>On 12/17/04 11:34 AM, "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com> wrote:
>
>  
>
>>We have a debate on how to interpret the following paragraph (RFC
>>    
>>
>3261,
>  
>
>>section 19.3):
>>
>>===========
>>19.3 Tags
>>   ...
>>
>>   When a tag is generated by a UA for insertion into a request or
>>   response, it MUST be globally unique and cryptographically random
>>   with at least 32 bits of randomness.  A property of this selection
>>   requirement is that a UA will place a different tag into the From
>>   header of an INVITE than it would place into the To header of the
>>   response to the same INVITE.  This is needed in order for a UA to
>>   invite itself to a session, a common case for "hairpinning" of
>>    
>>
>calls
>  
>
>>   in PSTN gateways.  Similarly, two INVITEs for different calls will
>>   have different From tags, and two responses for different calls
>>    
>>
>will
>  
>
>>   have different To tags.
>>
>>   ...
>>===========
>>
>>Interpretation 1: A tag needs to be globally unique across space (aka
>>    
>>
>UAs) but
>  
>
>>not across time because Call-ID (section 8.1.1.4) is already unique
>>    
>>
>across
>  
>
>>space and time for calls. So a same UAC can use a same >From tag in
>>    
>>
>different
>  
>
>>calls it imitates. And a same UAS can use a same To tag to respond to
>>different calls. A same UA uses different tags in >From and To
>>    
>>
>headers.
>  
>
>>Different UAs use different tags.
>>
>>Interpretation 2: A tag needs to be different for each call. So a same
>>    
>>
>UAC has
>  
>
>>to use two different tags in From header when it initiates two
>>    
>>
>different
>  
>
>>calls. And a same UAS has to use different tags in To headers for
>>    
>>
>different
>  
>
>>calls. 
>>
>>We would like to hear from the list which way we should interpret the
>>    
>>
>above
>  
>
>>paragraph or what is the right interpretation if both interpretations
>>    
>>
>are not
>  
>
>>accurate.
>>
>>Thanks.
>>
>>
>>Jin-Gen Wang
>>Level3 Communications, Inc.
>>
>>
>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>Use sipping@ietf.org for new developments on the application of sip
>>    
>>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
>  
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec 27 04:01:36 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22403
	for <sip-web-archive@ietf.org>; Mon, 27 Dec 2004 04:01:36 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ciqvg-0004DO-6l
	for sip-web-archive@ietf.org; Mon, 27 Dec 2004 04:12:40 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ciqip-0003NN-C2; Mon, 27 Dec 2004 03:59:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Ciqfl-00038h-Cl
	for sip@megatron.ietf.org; Mon, 27 Dec 2004 03:56:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22149
	for <sip@ietf.org>; Mon, 27 Dec 2004 03:56:12 -0500 (EST)
Received: from machine76.level3.com ([209.244.4.189] helo=scanner5.level3.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CiqqR-00046X-6n
	for sip@ietf.org; Mon, 27 Dec 2004 04:07:15 -0500
Received: from scanner5.level3.com (localhost [127.0.0.1])
	by localhost.level3.com (Postfix) with ESMTP
	id CADF6124C85; Mon, 27 Dec 2004 08:55:41 +0000 (GMT)
Received: from idc1exc0001.corp.global.level3.com
	(idc1exc0001.corp.global.level3.com [10.1.7.194])
	by scanner5.level3.com (Postfix) with SMTP
	id 73497124A99; Mon, 27 Dec 2004 08:55:41 +0000 (GMT)
Received: from idc1exc0002.corp.global.level3.com ([10.1.8.18]) by
	idc1exc0001.corp.global.level3.com with Microsoft
	SMTPSVC(6.0.3790.211); Mon, 27 Dec 2004 01:55:41 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] a question about the tag in From or To header
Date: Mon, 27 Dec 2004 01:55:40 -0700
Message-ID: <11FD90E74279C0489ECB6793F227C847044BFC1F@idc1exc0002.corp.global.level3.com>
Thread-Topic: [Sip] a question about the tag in From or To header
Thread-Index: AcTpiMaHvxtsUv05QbS9SoD+HOJtxgCZ/oBQ
From: "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com>
To: "Adam Roach" <adam@nostrum.com>
X-OriginalArrivalTime: 27 Dec 2004 08:55:41.0162 (UTC)
	FILETIME=[D7B1DCA0:01C4EBF1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955
Content-Transfer-Encoding: quoted-printable
Cc: Cullen Jennings <fluffy@cisco.com>, sip@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba
Content-Transfer-Encoding: quoted-printable

Thanks, Adam. You answered our question on the RFC 3261 compliance. Now =
what's the reason that a same UAC needs to use different From tags for =
different calls?

Thanks.

Jin-Gen Wang
Level3 Communications, Inc.


-----Original Message-----
From: Adam Roach [mailto:adam@nostrum.com]
Sent: Friday, December 24, 2004 12:18 AM
To: Wang, Jin-Gen
Cc: Nataraju A B; Cullen Jennings; sip@ietf.org
Subject: Re: [Sip] a question about the tag in From or To header


Wang, Jin-Gen wrote:

>Thanks for your reply. The From tag, Call-ID, and To tag are used to =
identify a dialog. Since Call-ID is already unique across time and =
space, it seems that it is sufficient the tags in From and To headers =
only need to be unique across space. Like ABN mentioned, interpretation =
1 leads to a simpler implementation. Our question is: does =
interpretation 1 violate RFC 3261?
> =20
>

Yes, it does. The text Cullen pointed out *comes* *from* RFC 3261. It=20
basically says that intrepretation 1 is wrong.

/a


>Thanks.
>
>Jin-Gen Wang
>Level3 Communications, Inc.
>
>-----Original Message-----
>From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com]
>Sent: Thursday, December 23, 2004 9:34 PM
>To: 'Cullen Jennings'; Wang, Jin-Gen; sip@ietf.org
>Subject: RE: [Sip] a question about the tag in From or To header
>
>
>Comments inline...
>
>Best Regards,
>Nataraju A.B.
>Kodiak Networks Ind Pvt Ltd.,
>Phone : +91 80 2222 7960 Xtn 555
>
>-----Original Message-----
>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
>Cullen Jennings
>Sent: Wednesday, December 22, 2004 9:27 PM
>To: Wang, Jin-Gen; sip@ietf.org
>Subject: Re: [Sip] a question about the tag in From or To header
>
>
>It seems that=20
>=20
>   Similarly, two INVITEs for different calls will
>   have different From tags, and two responses for different calls will
>   have different To tags."
>
>is pretty clear that you need to do Interpretation 2. Is there some
>problem
>with this and reason why you want to do 1?
>
>[ABN] the option 1 would be preferred to have simplicity in identifying
>the user from the from-tag itself....(that is an implementation issue
>only)
>
>On 12/17/04 11:34 AM, "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com> wrote:
>
> =20
>
>>We have a debate on how to interpret the following paragraph (RFC
>>   =20
>>
>3261,
> =20
>
>>section 19.3):
>>
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>19.3 Tags
>>   ...
>>
>>   When a tag is generated by a UA for insertion into a request or
>>   response, it MUST be globally unique and cryptographically random
>>   with at least 32 bits of randomness.  A property of this selection
>>   requirement is that a UA will place a different tag into the From
>>   header of an INVITE than it would place into the To header of the
>>   response to the same INVITE.  This is needed in order for a UA to
>>   invite itself to a session, a common case for "hairpinning" of
>>   =20
>>
>calls
> =20
>
>>   in PSTN gateways.  Similarly, two INVITEs for different calls will
>>   have different From tags, and two responses for different calls
>>   =20
>>
>will
> =20
>
>>   have different To tags.
>>
>>   ...
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>Interpretation 1: A tag needs to be globally unique across space (aka
>>   =20
>>
>UAs) but
> =20
>
>>not across time because Call-ID (section 8.1.1.4) is already unique
>>   =20
>>
>across
> =20
>
>>space and time for calls. So a same UAC can use a same >From tag in
>>   =20
>>
>different
> =20
>
>>calls it imitates. And a same UAS can use a same To tag to respond to
>>different calls. A same UA uses different tags in >From and To
>>   =20
>>
>headers.
> =20
>
>>Different UAs use different tags.
>>
>>Interpretation 2: A tag needs to be different for each call. So a same
>>   =20
>>
>UAC has
> =20
>
>>to use two different tags in From header when it initiates two
>>   =20
>>
>different
> =20
>
>>calls. And a same UAS has to use different tags in To headers for
>>   =20
>>
>different
> =20
>
>>calls.=20
>>
>>We would like to hear from the list which way we should interpret the
>>   =20
>>
>above
> =20
>
>>paragraph or what is the right interpretation if both interpretations
>>   =20
>>
>are not
> =20
>
>>accurate.
>>
>>Thanks.
>>
>>
>>Jin-Gen Wang
>>Level3 Communications, Inc.
>>
>>
>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>Use sipping@ietf.org for new developments on the application of sip
>>   =20
>>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
> =20
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec 27 17:02:38 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08545
	for <sip-web-archive@ietf.org>; Mon, 27 Dec 2004 17:02:38 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cj37d-0003su-8E
	for sip-web-archive@ietf.org; Mon, 27 Dec 2004 17:13:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cj2lE-0008J0-Nn; Mon, 27 Dec 2004 16:50:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj1tv-0002DU-DQ
	for sip@megatron.ietf.org; Mon, 27 Dec 2004 15:55:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21976
	for <sip@ietf.org>; Mon, 27 Dec 2004 15:55:33 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cj24h-0006nz-D7 for sip@ietf.org; Mon, 27 Dec 2004 16:06:43 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-3.cisco.com with ESMTP; 27 Dec 2004 14:04:11 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBRKsxdP006090;
	Mon, 27 Dec 2004 12:54:59 -0800 (PST)
Received: from [192.168.1.102] (sjc-vpn4-798.cisco.com [10.21.83.29])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVA58536;
	Mon, 27 Dec 2004 12:54:59 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Mon, 27 Dec 2004 12:13:24 -0700
Subject: Re: [Sip] a question about the tag in From or To header
From: Cullen Jennings <fluffy@cisco.com>
To: "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com>, Adam Roach <adam@nostrum.com>
Message-ID: <BDF5ACE4.20D23%fluffy@cisco.com>
In-Reply-To: <11FD90E74279C0489ECB6793F227C847044BFC1F@idc1exc0002.corp.global.level3.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8
Content-Transfer-Encoding: 7bit


Not sure I know the answer to why it says this, but the problem is, now that
it does say this, some implementation might be counting on this when they
receive things. For example, they might use it as index to a hash with an
assumption that collisions will be rare.


On 12/27/04 1:55 AM, "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com> wrote:

> Thanks, Adam. You answered our question on the RFC 3261 compliance. Now what's
> the reason that a same UAC needs to use different From tags for different
> calls?
> 
> Thanks.
> 
> Jin-Gen Wang
> Level3 Communications, Inc.
> 
> 
> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Friday, December 24, 2004 12:18 AM
> To: Wang, Jin-Gen
> Cc: Nataraju A B; Cullen Jennings; sip@ietf.org
> Subject: Re: [Sip] a question about the tag in From or To header
> 
> 
> Wang, Jin-Gen wrote:
> 
>> Thanks for your reply. The From tag, Call-ID, and To tag are used to identify
>> a dialog. Since Call-ID is already unique across time and space, it seems
>> that it is sufficient the tags in From and To headers only need to be unique
>> across space. Like ABN mentioned, interpretation 1 leads to a simpler
>> implementation. Our question is: does interpretation 1 violate RFC 3261?
>>  
>> 
> 
> Yes, it does. The text Cullen pointed out *comes* *from* RFC 3261. It
> basically says that intrepretation 1 is wrong.
> 
> /a
> 
> 
>> Thanks.
>> 
>> Jin-Gen Wang
>> Level3 Communications, Inc.
>> 
>> -----Original Message-----
>> From: Nataraju A B [mailto:bnataraju@kodiaknetworks.com]
>> Sent: Thursday, December 23, 2004 9:34 PM
>> To: 'Cullen Jennings'; Wang, Jin-Gen; sip@ietf.org
>> Subject: RE: [Sip] a question about the tag in From or To header
>> 
>> 
>> Comments inline...
>> 
>> Best Regards,
>> Nataraju A.B.
>> Kodiak Networks Ind Pvt Ltd.,
>> Phone : +91 80 2222 7960 Xtn 555
>> 
>> -----Original Message-----
>> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
>> Cullen Jennings
>> Sent: Wednesday, December 22, 2004 9:27 PM
>> To: Wang, Jin-Gen; sip@ietf.org
>> Subject: Re: [Sip] a question about the tag in From or To header
>> 
>> 
>> It seems that 
>> 
>>   Similarly, two INVITEs for different calls will
>>   have different From tags, and two responses for different calls will
>>   have different To tags."
>> 
>> is pretty clear that you need to do Interpretation 2. Is there some
>> problem
>> with this and reason why you want to do 1?
>> 
>> [ABN] the option 1 would be preferred to have simplicity in identifying
>> the user from the from-tag itself....(that is an implementation issue
>> only)
>> 
>> On 12/17/04 11:34 AM, "Wang, Jin-Gen" <Jin-Gen.Wang@Level3.com> wrote:
>> 
>>  
>> 
>>> We have a debate on how to interpret the following paragraph (RFC
>>>    
>>> 
>> 3261,
>>  
>> 
>>> section 19.3):
>>> 
>>> ===========
>>> 19.3 Tags
>>>   ...
>>> 
>>>   When a tag is generated by a UA for insertion into a request or
>>>   response, it MUST be globally unique and cryptographically random
>>>   with at least 32 bits of randomness.  A property of this selection
>>>   requirement is that a UA will place a different tag into the From
>>>   header of an INVITE than it would place into the To header of the
>>>   response to the same INVITE.  This is needed in order for a UA to
>>>   invite itself to a session, a common case for "hairpinning" of
>>>    
>>> 
>> calls
>>  
>> 
>>>   in PSTN gateways.  Similarly, two INVITEs for different calls will
>>>   have different From tags, and two responses for different calls
>>>    
>>> 
>> will
>>  
>> 
>>>   have different To tags.
>>> 
>>>   ...
>>> ===========
>>> 
>>> Interpretation 1: A tag needs to be globally unique across space (aka
>>>    
>>> 
>> UAs) but
>>  
>> 
>>> not across time because Call-ID (section 8.1.1.4) is already unique
>>>    
>>> 
>> across
>>  
>> 
>>> space and time for calls. So a same UAC can use a same >From tag in
>>>    
>>> 
>> different
>>  
>> 
>>> calls it imitates. And a same UAS can use a same To tag to respond to
>>> different calls. A same UA uses different tags in >From and To
>>>    
>>> 
>> headers.
>>  
>> 
>>> Different UAs use different tags.
>>> 
>>> Interpretation 2: A tag needs to be different for each call. So a same
>>>    
>>> 
>> UAC has
>>  
>> 
>>> to use two different tags in From header when it initiates two
>>>    
>>> 
>> different
>>  
>> 
>>> calls. And a same UAS has to use different tags in To headers for
>>>    
>>> 
>> different
>>  
>> 
>>> calls. 
>>> 
>>> We would like to hear from the list which way we should interpret the
>>>    
>>> 
>> above
>>  
>> 
>>> paragraph or what is the right interpretation if both interpretations
>>>    
>>> 
>> are not
>>  
>> 
>>> accurate.
>>> 
>>> Thanks.
>>> 
>>> 
>>> Jin-Gen Wang
>>> Level3 Communications, Inc.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol
>>> Use sip-implementors@cs.columbia.edu for questions on current sip
>>> Use sipping@ietf.org for new developments on the application of sip
>>>    
>>> 
>> 
>> 
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>> 
>> 
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>> 
>>  
>> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Mon Dec 27 17:09:59 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09321
	for <sip-web-archive@ietf.org>; Mon, 27 Dec 2004 17:09:59 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cj3Ej-0004BH-Jt
	for sip-web-archive@ietf.org; Mon, 27 Dec 2004 17:21:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cj2lf-0000HU-SO; Mon, 27 Dec 2004 16:51:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj1zN-0005SV-Kn
	for sip@megatron.ietf.org; Mon, 27 Dec 2004 16:01:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22852
	for <sip@ietf.org>; Mon, 27 Dec 2004 16:01:12 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Cj2A8-00075w-Vj for sip@ietf.org; Mon, 27 Dec 2004 16:12:22 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 27 Dec 2004 13:07:07 -0800
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com
	[171.71.163.15])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBRL0dHn025077;
	Mon, 27 Dec 2004 13:00:39 -0800 (PST)
Received: from [192.168.1.102] (sjc-vpn4-798.cisco.com [10.21.83.29])
	by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVA58928;
	Mon, 27 Dec 2004 13:00:38 -0800 (PST)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Mon, 27 Dec 2004 14:00:38 -0700
Subject: Re: [Sip] refer-with-norefersub
From: Cullen Jennings <fluffy@cisco.com>
To: Adam Roach <adam@nostrum.com>
Message-ID: <BDF5C606.20D63%fluffy@cisco.com>
In-Reply-To: <41C0AC11.5080208@nostrum.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Cc: "sip@ietf.org" <sip@ietf.org>, Orit Levin <oritl@microsoft.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit

On 12/15/04 1:26 PM, "Adam Roach" <adam@nostrum.com> wrote:

> Cullen Jennings wrote:
> 
>> I think I understand that often the subscriptions is of no use and what you
>> want to do here.
>> 
>> It seems like putting a tag in the uri of the refer like ";norefersub" could
>> be used as a hint not to create the implicit subscription. It does not seem
>> like the Supported Require stuff is needed.
>> 
>> Would this work and do what you want?
>>  
>> 
> 
> This seems wrong to me -- largely because you're saying that, for
> certain URIs, based on local policy decisions, we are supposed to ignore
> MUST-strength normative statements of RFC3515 (e.g. "The NOTIFY
> mechanism defined in [2] MUST be used to inform the agent sending the
> REFER of the status of the reference.")
> 
> It seems very much to me that changing behavior to be noncompliant with
> an RFC requires another RFC.
> 
> I could easily formulate scenarios where this proposal actually causes
> interoperability issues, but I believe that the objection on principle
> is sufficiently strong that it's not worth wasting anyone's time
> outlining the practical problems.
> 
> /a

Good point - I agree with need RFC - my only point was it seems like you
could do this without Require stuff but perhaps 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Tue Dec 28 15:47:00 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25170
	for <sip-web-archive@ietf.org>; Tue, 28 Dec 2004 15:47:00 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CjOQA-0004dq-Ni
	for sip-web-archive@ietf.org; Tue, 28 Dec 2004 15:58:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CjOBj-0006O0-RL; Tue, 28 Dec 2004 15:43:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CjO91-0004mC-Cz
	for sip@megatron.ietf.org; Tue, 28 Dec 2004 15:40:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24892
	for <sip@ietf.org>; Tue, 28 Dec 2004 15:40:36 -0500 (EST)
Received: from motgate2.mot.com ([144.189.100.101])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjOJz-0004VI-JL
	for sip@ietf.org; Tue, 28 Dec 2004 15:52:00 -0500
Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243])
	by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id iBSKjchX020872
	for <sip@ietf.org>; Tue, 28 Dec 2004 13:45:38 -0700 (MST)
Received: from il06exm13.corp.mot.com (il06exm13.corp.mot.com [10.0.111.13])
	by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id iBSKdBj4029774
	for <sip@ietf.org>; Tue, 28 Dec 2004 14:39:11 -0600
Received: from bulb (bulb.corp.mot.com [10.14.25.99]) by
	il06exm13.corp.mot.com with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2657.72)
	id YGWB85L7; Tue, 28 Dec 2004 14:40:35 -0600
Date: Tue, 28 Dec 2004 15:40:34 -0500 (EST)
From: Srini Krishnamoorthy <ksrini@motorola.com>
X-Sender: ksrini@bulb.corp.mot.com
To: sip@ietf.org
Message-ID: <Pine.LNX.4.21.0412281423010.8834-100000@bulb.corp.mot.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: [Sip] 3840 Device ID -  SIP Capababilties
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ksrini@motorola.com
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22


Dear All,

 Some time last year there was a discussion about Device IDs and
 SIP capabilities - what was the consensus on that? 

 Was a instance-id or a device-id included? Or is it addressed
 in some other piece of work?  I couldn't find any text in 
 RFC3840 (SIP Cababilities) on this subject

 Can any one help? 

 Here is link to that the original discussion:
   http://www1.ietf.org/mail-archive/web/sip/current/msg08369.html


Thanks very much
-- 
Srini K




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec 29 11:34:22 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21961
	for <sip-web-archive@ietf.org>; Wed, 29 Dec 2004 11:34:22 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CjgxP-0002wj-3p
	for sip-web-archive@ietf.org; Wed, 29 Dec 2004 11:45:56 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Cjgkp-0003RX-BP; Wed, 29 Dec 2004 11:32:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjgfp-0002QD-4M
	for sip@megatron.ietf.org; Wed, 29 Dec 2004 11:27:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21497
	for <sip@ietf.org>; Wed, 29 Dec 2004 11:27:42 -0500 (EST)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjgqy-0002lg-Nk
	for sip@ietf.org; Wed, 29 Dec 2004 11:39:17 -0500
Received: from rtp-core-2.cisco.com (64.102.124.13)
	by rtp-iport-2.cisco.com with ESMTP; 29 Dec 2004 11:27:14 -0500
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com
	[64.102.16.27])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBTGRBVA017050; 
	Wed, 29 Dec 2004 11:27:11 -0500 (EST)
Received: from cisco.com (rtp-vpn1-231.cisco.com [10.82.224.231])
	by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BEG81683;
	Wed, 29 Dec 2004 08:27:09 -0800 (PST)
Message-ID: <41D2DADD.9030902@cisco.com>
Date: Wed, 29 Dec 2004 11:27:09 -0500
From: Kevin Lingle <klingle@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.0.1) Gecko/20020823
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Charles Eckel <eckelcu@cisco.com>
Subject: Re: [Sip] mib-08
References: <AAB4B3D3CF0F454F98272CBE187FDE2F038A9F1C@is0004avexu1.global.avaya.com>
	<4193EB0F.1090003@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>,
        Steve Langstaff <steve.langstaff@citel.com>,
        Cullen Jennings <fluffy@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Content-Transfer-Encoding: 7bit

hi charles,

sorry for the delay in response.  jean-francios and i
discussed this today and he will update the mib module
based on your comments.

we are expecting to publish rev 09 early next week.

kevin

Charles Eckel wrote:
> Just a few recommended clarifications:
> 
> sipStatsInbounds OBJECT-TYPE
> Description: should state excludes retransmissions
> 
> sipStatsRetries OBJECT-TYPE
> Description: should replace "total number of INVITE retries" with "total 
> number of request retransmissions, could be multiple per request"
> 
> sipStatsRetryFinalResponses
> Description: should state there could be multiple per response
> 
> Cheers,
> Charles
> 
> 
> Romascanu, Dan (Dan) wrote:
> 
>> Steve,
>>
>> Actually implementation experience and interoperability is required 
>> only when time comes to advance a standards track Proposed Standard to 
>> Draft Standard phase. Although 'pre-standard' implementations are not 
>> discouraged in I-D phase, one cannot ensure interoperable versions 
>> before the standard, because the OID allocation for the root of the 
>> MIB module under mib-2 is being performed by IANA only very late, 
>> prior to the RFC publication.
>>
>> Whether the document will be a standards track, or not, is an IESG 
>> decision based on the WG recommendation.
>> Regards,
>>
>> Dan
>>
>>
>>
>>  > -----Original Message-----
>>  > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On
>>  > Behalf Of Steve Langstaff
>>  > Sent: 09 November, 2004 6:37 PM
>>  > To: Kevin Lingle
>>  > Cc: sip@ietf.org; Cullen Jennings
>>  > Subject: RE: [Sip] mib-08
>>  >
>>  >
>>  > KL: "we need to move the I-D forward so we can get a RFC that
>>  > can get some implementation experience."
>>  >
>>  > I thought that the I-D phase was the time to get the
>>  > implementation experience. Is it your intention that the RFC
>>  > will be "Experimental" or "Informational" before getting this
>>  > implementation experience, and then become a standard afterwards?
>>  >
>>  > --
>>  > Steve Langstaff.
>>  >
>>  >
>>  > -----Original Message-----
>>  > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
>>  > Kevin Lingle
>>  > Sent: 08 November 2004 17:26
>>  > To: Cullen Jennings
>>  > Cc: sip@ietf.org
>>  > Subject: Re: [Sip] mib-08
>>  > [snip]
>>  >
>>  > we need to move the
>>  > I-D forward so we can get a RFC that can get some implementation
>>  > experience.
>>  >
>>  > kevin
>>  >
>>  > _______________________________________________
>>  > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>  > This list is for NEW development of the core SIP Protocol
>>  > Use sip-implementors@cs.columbia.edu for questions on current sip
>>  > Use sipping@ietf.org for new developments on the application of sip
>>  >
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>>
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Wed Dec 29 17:29:43 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26515
	for <sip-web-archive@ietf.org>; Wed, 29 Dec 2004 17:29:43 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CjmVM-0005m9-Kj
	for sip-web-archive@ietf.org; Wed, 29 Dec 2004 17:41:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CjmHD-000873-Fi; Wed, 29 Dec 2004 17:26:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CjmFp-00071U-2o
	for sip@megatron.ietf.org; Wed, 29 Dec 2004 17:25:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26277
	for <sip@ietf.org>; Wed, 29 Dec 2004 17:25:14 -0500 (EST)
Received: from ondar.cablelabs.com ([192.160.73.61])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjmR0-0005fw-Nx
	for sip@ietf.org; Wed, 29 Dec 2004 17:36:52 -0500
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20])
	by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id iBTMOU1e010071; 
	Wed, 29 Dec 2004 15:24:31 -0700 (MST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] mib-08
Date: Wed, 29 Dec 2004 15:24:30 -0700
Message-ID: <CD6CE349CFD30D40BF5E13B3E0D8480406A473@srvxchg.cablelabs.com>
Thread-Topic: [Sip] mib-08
Thread-Index: AcTtxKalh0/YEH0IR2OZ+w5O97VdIwALvxbA
From: "Jean-Francois Mule" <jf.mule@cablelabs.com>
To: "Charles Eckel" <eckelcu@cisco.com>
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org, "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>,
        Kevin Lingle <klingle@cisco.com>, Cullen Jennings <fluffy@cisco.com>,
        Steve Langstaff <steve.langstaff@citel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Content-Transfer-Encoding: quoted-printable

Charles,

   Here are the changes reflected in the object descriptions.
   This should address your comment, let me know otherwise.

Jean-Francois=20

Charles wrote:
> > sipStatsInbounds OBJECT-TYPE
> > Description: should state excludes retransmissions

New object def:
   sipStatsInbounds OBJECT-TYPE    =20
       SYNTAX      Counter32    =20
       MAX-ACCESS  read-only    =20
       STATUS      current    =20
       DESCRIPTION    =20
            "This object reflects the total number of requests    =20
             received by the SIP entity. Retransmissions are
             counted separately and are not reflected in this
             counter."
       REFERENCE    =20
            "RFC 3261, Section 7.1"      =20
       ::=3D { sipMethodStatsEntry 3 }    =20


> > sipStatsRetries OBJECT-TYPE
> > Description: should replace "total number of INVITE retries" with=20
> > "total
> > number of request retransmissions, could be multiple per request"
New object def:
   sipStatsRetries OBJECT-TYPE    =20
       SYNTAX      Counter32    =20
       MAX-ACCESS  read-only    =20
       STATUS      current    =20
       DESCRIPTION    =20
            "This object reflects the total number of request
             retransmissions that have been sent by the SIP
             entity. Note that there could be multiple
             retransmissions per request."    =20
       ::=3D { sipCommonStatsRetryEntry 2 }    =20
Btw - good catch on the removal of "INVITE" - we should have deleted
this when we introduced sipStatsRetryMethod.


> >=20
> > sipStatsRetryFinalResponses
> > Description: should state there could be multiple per response
   sipStatsRetryFinalResponses OBJECT-TYPE    =20
       SYNTAX      Counter32    =20
       MAX-ACCESS  read-only    =20
       STATUS      current    =20
       DESCRIPTION    =20
            "This object reflects the total number of Final Response   =20
             retries that have been sent by the SIP entity.
             Note that there could be multiple retransmissions
             per request."    =20
       ::=3D { sipCommonStatsRetryEntry 3 }    =20
   =20




> -----Original Message-----
> From: Kevin Lingle [mailto:klingle@cisco.com]=20
> Sent: Wednesday, December 29, 2004 9:27 AM
> To: Charles Eckel
> Cc: sip@ietf.org; Romascanu, Dan (Dan); Steve Langstaff;=20
> Cullen Jennings
> Subject: Re: [Sip] mib-08
>=20
>=20
> hi charles,
>=20
> sorry for the delay in response.  jean-francios and i
> discussed this today and he will update the mib module
> based on your comments.
>=20
> we are expecting to publish rev 09 early next week.
>=20
> kevin
>=20
> Charles Eckel wrote:
> > Just a few recommended clarifications:
> >=20
> > sipStatsInbounds OBJECT-TYPE
> > Description: should state excludes retransmissions
> >=20
> > sipStatsRetries OBJECT-TYPE
> > Description: should replace "total number of INVITE retries" with=20
> > "total
> > number of request retransmissions, could be multiple per request"
> >=20
> > sipStatsRetryFinalResponses
> > Description: should state there could be multiple per response
> >=20
> > Cheers,
> > Charles

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec 30 16:06:23 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17462
	for <sip-web-archive@ietf.org>; Thu, 30 Dec 2004 16:06:23 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1Ck7gR-0003qz-S4
	for sip-web-archive@ietf.org; Thu, 30 Dec 2004 16:18:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ck780-00036a-F8; Thu, 30 Dec 2004 15:42:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CilJv-000788-1e
	for sip@megatron.ietf.org; Sun, 26 Dec 2004 22:13:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16567
	for <sip@ietf.org>; Sun, 26 Dec 2004 22:13:16 -0500 (EST)
Received: from david.siemens.com.cn ([194.138.202.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CilTS-0004Gz-Mo
	for sip@ietf.org; Sun, 26 Dec 2004 22:24:18 -0500
Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52])
	by david.siemens.com.cn (8.11.7/8.11.7) with ESMTP id iBR34tZ22138
	for <sip@ietf.org>; Mon, 27 Dec 2004 11:04:56 +0800 (CST)
Received: from pekw096e.cn001.siemens.net (pekw096e.cn001.siemens.net
	[140.231.51.134])
	by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id iBR3Bue04353
	for <sip@ietf.org>; Mon, 27 Dec 2004 11:11:57 +0800 (CST)
Received: by pekw096e with Internet Mail Service (5.5.2657.72)
	id <Z4R1RL5R>; Mon, 27 Dec 2004 11:11:56 +0800
Message-ID: <31F31018FE2DC941A70BD30477510B0C034C0A8C@biscm02>
From: "Chen Zaifeng,SCNB R&D NNC(BJ)" <zaifeng.chen@siemens.com>
To: sip@ietf.org
Date: Mon, 27 Dec 2004 11:23:22 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Spam-Score: 3.8 (+++)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
X-Mailman-Approved-At: Thu, 30 Dec 2004 15:42:34 -0500
Cc: "Wang Xiao Hua \(Eric\),SCNB BM NGN\(BJ\)" <wang.xiaohua@siemens.com>
Subject: [Sip] How to distinguish a session refreshing Re-INVITE and a call
	resu ming Re-INVITE?
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1899064411=="
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1899064411==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4EBC3.6B80C8EE"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4EBC3.6B80C8EE
Content-Type: text/plain

Dear All:
Suppose that a SIP UA has been held by remote side, and during call hold it receives a Re-INVITE for session refreshing from the same remote entity. 
My question is:  How can the UA distinguish the intention of the Re-INVITE from the viewpoint of spec, as currently it is also waiting for a Re-INVITE for call resume?
Thanks!
Best Regards
Chen




------_=_NextPart_001_01C4EBC3.6B80C8EE
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>How to distinguish a session refreshing Re-INVITE and a call =
resuming Re-INVITE?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Dear All:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Suppose that a SIP UA has been held =
by remote side, and during call hold it receives a Re-INVITE for =
session refreshing from the same remote entity. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">My question is:&nbsp; How can the UA =
distinguish the intention of the Re-INVITE from the viewpoint of spec, =
as currently it is also waiting for a Re-INVITE for call =
resume?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks!</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Best Regards</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Chen</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C4EBC3.6B80C8EE--


--===============1899064411==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1899064411==--



From sip-bounces@ietf.org  Thu Dec 30 19:54:23 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02872
	for <sip-web-archive@ietf.org>; Thu, 30 Dec 2004 19:54:23 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CkBF6-0000n4-N4
	for sip-web-archive@ietf.org; Thu, 30 Dec 2004 20:06:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CkB1a-0002Uw-MU; Thu, 30 Dec 2004 19:52:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CkB0n-0002Kq-Ad
	for sip@megatron.ietf.org; Thu, 30 Dec 2004 19:51:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02681
	for <sip@ietf.org>; Thu, 30 Dec 2004 19:51:24 -0500 (EST)
Received: from endor.rfc3261.net ([212.112.227.208])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkBCE-0000gw-1p
	for sip@ietf.org; Thu, 30 Dec 2004 20:03:14 -0500
Received: from localhost (localhost [127.0.0.1])
	by endor.rfc3261.net (Postfix) with ESMTP id 305F8260013;
	Fri, 31 Dec 2004 01:50:52 +0100 (CET)
Received: from endor.rfc3261.net ([127.0.0.1])
	by localhost (endor [127.0.0.1]) (amavisd-new, port 10024) with LMTP
	id 04247-07; Fri, 31 Dec 2004 01:50:51 +0100 (CET)
Received: from cloudcity.ohlmeier.home (G9d01.g.pppool.de [80.185.157.1])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by endor.rfc3261.net (Postfix) with ESMTP id 8CC1826000A;
	Fri, 31 Dec 2004 01:50:51 +0100 (CET)
From: Nils Ohlmeier <lists@ohlmeier.org>
To: sip@ietf.org
Subject: Re: [Sip] How to distinguish a session refreshing Re-INVITE and a
	call resu ming Re-INVITE?
Date: Fri, 31 Dec 2004 01:50:49 +0100
User-Agent: KMail/1.7.2
References: <31F31018FE2DC941A70BD30477510B0C034C0A8C@biscm02>
In-Reply-To: <31F31018FE2DC941A70BD30477510B0C034C0A8C@biscm02>
X-Dont-Stare: at me
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200412310150.49797.lists@ohlmeier.org>
X-Virus-Scanned: by amavisd-new (Debian) at endor.rfc3261.net
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: "Wang Xiao Hua \(Eric\), SCNB BM NGN\(BJ\)" <wang.xiaohua@siemens.com>,
        "Chen Zaifeng, SCNB R&D NNC\(BJ\)" <zaifeng.chen@siemens.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit

If the SDP body of the re-INVITE changes your sendrecv status per RFC 3264 it 
is a re-INVITE for resume (or any other status change), if not it is a 
re-INVITE which refreshes the session only.

BTW: this is more a question for sip-implementors like written in the footer 
of this mail.

Regards
  Nils Ohlmeier

On Monday 27 December 2004 04:23, Chen Zaifeng,SCNB R&D NNC(BJ) wrote:
> Dear All:
> Suppose that a SIP UA has been held by remote side, and during call hold it
> receives a Re-INVITE for session refreshing from the same remote entity. My
> question is:  How can the UA distinguish the intention of the Re-INVITE
> from the viewpoint of spec, as currently it is also waiting for a Re-INVITE
> for call resume? Thanks!
> Best Regards
> Chen

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec 30 22:08:26 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09782
	for <sip-web-archive@ietf.org>; Thu, 30 Dec 2004 22:08:26 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CkDKs-0003hN-Eu
	for sip-web-archive@ietf.org; Thu, 30 Dec 2004 22:20:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CkD3Z-0007KX-8B; Thu, 30 Dec 2004 22:02:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CkD2G-0006r4-TH
	for sip@megatron.ietf.org; Thu, 30 Dec 2004 22:01:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09430
	for <sip@ietf.org>; Thu, 30 Dec 2004 22:01:02 -0500 (EST)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkDDh-0003Xo-VI
	for sip@ietf.org; Thu, 30 Dec 2004 22:12:55 -0500
Received: from sj-core-4.cisco.com (171.68.223.138)
	by sj-iport-4.cisco.com with ESMTP; 30 Dec 2004 19:00:53 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
	[161.44.122.62])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iBV30S1X024093;
	Thu, 30 Dec 2004 19:00:29 -0800 (PST)
Received: from cisco.com (che-vpn-cluster-2-24.cisco.com [10.86.242.24])
	by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOA52817;
	Thu, 30 Dec 2004 22:00:27 -0500 (EST)
Message-ID: <41D4C0CB.6040409@cisco.com>
Date: Thu, 30 Dec 2004 22:00:27 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nils Ohlmeier <lists@ohlmeier.org>
Subject: Re: [Sip] How to distinguish a session refreshing Re-INVITE and a
	call resu ming Re-INVITE?
References: <31F31018FE2DC941A70BD30477510B0C034C0A8C@biscm02>
	<200412310150.49797.lists@ohlmeier.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org,
        "Wang Xiao Hua \(Eric\),
	SCNB BM NGN\(BJ\)" <wang.xiaohua@siemens.com>,
        "Chen Zaifeng,
	SCNB R&D NNC\(BJ\)" <zaifeng.chen@siemens.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit



Nils Ohlmeier wrote:
> If the SDP body of the re-INVITE changes your sendrecv status per RFC 3264 it 
> is a re-INVITE for resume (or any other status change), if not it is a 
> re-INVITE which refreshes the session only.
> 
> BTW: this is more a question for sip-implementors like written in the footer 
> of this mail.

I don't disagree, but I have a different way of thinking about this.

Session refresh is not something special. If session timer is in use, 
then *every* reinvite and update is a session refresh, incidental to 
whatever else it does.

If you want to do a session refresh, and you don't want to do anything 
else, then you send a reinvite or update that doesn't, from your point 
of view, suggest changing anything. Even then, there remains a 
possibility that changes will be made by the other end. There is nothing 
you can do to prevent that.

Lets consider that case of a call between A and B, where session timer 
is enabled, A is the refresher. At some time B decides to put the call 
on hold, so sends a reinvite with a=sendonly, and A responds with 
a=recvonly. (Incidentally, this refreshes the session even though A is 
the refresher.)

At some later time, A decides it is time to refresh by sending a 
reinvite. Presumably A didn't *want* to be on hold. So I would expect it 
to send an offer with a=sendrecv. If B still wants to be on hold, it 
will respond with a=sendonly.

	Paul

> Regards
>   Nils Ohlmeier
> 
> On Monday 27 December 2004 04:23, Chen Zaifeng,SCNB R&D NNC(BJ) wrote:
> 
>>Dear All:
>>Suppose that a SIP UA has been held by remote side, and during call hold it
>>receives a Re-INVITE for session refreshing from the same remote entity. My
>>question is:  How can the UA distinguish the intention of the Re-INVITE
>>from the viewpoint of spec, as currently it is also waiting for a Re-INVITE
>>for call resume? Thanks!
>>Best Regards
>>Chen
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-bounces@ietf.org  Thu Dec 30 22:35:04 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11194
	for <sip-web-archive@ietf.org>; Thu, 30 Dec 2004 22:35:04 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CkDkd-0004HZ-NF
	for sip-web-archive@ietf.org; Thu, 30 Dec 2004 22:46:56 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1CkDRm-00031n-SL; Thu, 30 Dec 2004 22:27:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1CkDIh-0001kM-C6
	for sip@megatron.ietf.org; Thu, 30 Dec 2004 22:18:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10389
	for <sip@ietf.org>; Thu, 30 Dec 2004 22:18:01 -0500 (EST)
Received: from endor.rfc3261.net ([212.112.227.208])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkDU8-0003v1-II
	for sip@ietf.org; Thu, 30 Dec 2004 22:29:53 -0500
Received: from localhost (localhost [127.0.0.1])
	by endor.rfc3261.net (Postfix) with ESMTP id C3A68260013;
	Fri, 31 Dec 2004 04:17:29 +0100 (CET)
Received: from endor.rfc3261.net ([127.0.0.1])
	by localhost (endor [127.0.0.1]) (amavisd-new, port 10024) with LMTP
	id 13096-04; Fri, 31 Dec 2004 04:17:29 +0100 (CET)
Received: from cloudcity.ohlmeier.home (G9d01.g.pppool.de [80.185.157.1])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by endor.rfc3261.net (Postfix) with ESMTP id 2D01126000A;
	Fri, 31 Dec 2004 04:17:29 +0100 (CET)
From: Nils Ohlmeier <lists@ohlmeier.org>
To: sip@ietf.org
Subject: Re: [Sip] How to distinguish a session refreshing Re-INVITE and a
	call resu ming Re-INVITE?
Date: Fri, 31 Dec 2004 04:17:27 +0100
User-Agent: KMail/1.7.2
References: <31F31018FE2DC941A70BD30477510B0C034C0A8C@biscm02>
	<200412310150.49797.lists@ohlmeier.org>
	<41D4C0CB.6040409@cisco.com>
In-Reply-To: <41D4C0CB.6040409@cisco.com>
X-Dont-Stare: at me
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200412310417.27380.lists@ohlmeier.org>
X-Virus-Scanned: by amavisd-new (Debian) at endor.rfc3261.net
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: "Wang Xiao Hua \(Eric\), SCNB BM NGN\(BJ\)" <wang.xiaohua@siemens.com>,
        Paul Kyzivat <pkyzivat@cisco.com>,
        "Chen Zaifeng,
	SCNB R&D NNC\(BJ\)" <zaifeng.chen@siemens.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit

On Friday 31 December 2004 04:00, Paul Kyzivat wrote:
> Nils Ohlmeier wrote:
> > If the SDP body of the re-INVITE changes your sendrecv status per RFC
> > 3264 it is a re-INVITE for resume (or any other status change), if not it
> > is a re-INVITE which refreshes the session only.
> >
> > BTW: this is more a question for sip-implementors like written in the
> > footer of this mail.
>
> I don't disagree, but I have a different way of thinking about this.
>
> Session refresh is not something special. If session timer is in use,
> then *every* reinvite and update is a session refresh, incidental to
> whatever else it does.

Ok, ok, (as usual ;) I forgot to mention, that also the re-INVITE which 
changes the sendrecv status refreshes the session.
So basically every re-INVITE is a session refresher. And if the SDP changes 
the sendrecv status it also a resume. (The resume is a subset of the session 
refresher.)

Regards
  Nils Ohlmeier

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip